dwmw2 / mphidflash Goto Github PK

As we've now addressed a bunch of issues that have been lying here for many 
years, I felt it was time for a new release... Please review/comment on r8 - 
r16.

Once we're happy, we need executables for distribution. I can take care of 64 
bit Linux and Mac OS-X, but having trouble producing 32-bit Linux, and can't do 
Windows - again, we need 32 and 64 bit versions...

What steps will reproduce the problem?
1. program de pic18f4550 with HIDbootloader from Microchip USB framework using 
a pickit2 programmer
2. transfer an hex file to te microcontroller
3. The task is done

What is the expected output? What do you see instead?
te aplication isn´t start, te microcontroller is still in bootloader mode

What version of the product are you using? On what operating system?

i'm using the last 1.6

Please provide any additional information below.

When i use the HIDbootloader that Microchip provides for window, it works!

When I try to write a program :

./mphidflash -w file.hex
USB HID device found
  Device family: PIC18
  Program memory: 20480 bytes free. 8 bytes free. 
Erasing...
Writing hex file 'USB Device - Libusb - Generic Driver - C18 - PICDEM 
FSUSB.hex':.....................................................................
..........................................
Verifying:.
./mphidflash Error: Verify failed

And breaks the bootloader.
I'm using the last svn version under Linux.

My think is that the terminal window should not disappear at the end of 
programming if the programming went wrong:
I use the -reset flag and I haven't time sufficient to read the message at the 
end.

I think that it's ok to stick with the auto-closing of the window if everything 
was fine, but one should confirm with at least a "PRESS A KEY..." to allow him 
to fully read any error encountered in the programming.

Just my idea...

Sincerely

Stefano

What steps will reproduce the problem?
1. connect board with PIC, forgetting to set Linux udev rules for file 
permissions
2. run "mphidflash -w EBF_EBBv13_and_above.hex -r" and receive "Error: Device 
not found (is device attached and in Bootloader mode?)"
3. run "mphidflash -d3 -w EBF_EBBv13_and_above.hex -r" and receive only the 
same error.

What is the expected output? What do you see instead?

With "-d 3" expected to see a lot of debugging output. Saw none. When I hacked 
in hid_set_usb_debug() into usb-linux.c (see patch below), I got the debug 
output I needed.

You might also want to consider changing the error message hint from "is device 
attached and in Bootloader mode?" to include something about access or 
permissions.

What version of the product are you using? On what operating system?

1.4 on Ubuntu 10.04 x86_64

Please provide any additional information below.

v1.4 Code was downloaded from
https://code.google.com/p/eggbotcode/downloads/detail?name=mphidflash_1_4.zip&ca
n=2&q=


diff -u mphidflash-1.4.orig/usb-linux.c mphidflash/usb-linux.c
--- mphidflash-1.4.orig/usb-linux.c 2010-07-09 22:02:38.000000000 -0400
+++ mphidflash/usb-linux.c  2010-12-22 12:48:48.342691545 -0500
@@ -82,6 +82,11 @@
    matcher.product_id = productID;
    matcher.matcher_fn = NULL;

+   if (debugLevel >= DEBUG_USB) {
+       hid_set_debug(HID_DEBUG_ALL);
+       hid_set_usb_debug(HID_DEBUG_ALL);
+   }
+
    if(HID_RET_SUCCESS == hid_init()) {
        status = ERR_USB_INIT2;
        if((hid = hid_new_HIDInterface())) {

ammend file name in header comment

Hi,

Recently, I use PIC32MX675F512H.

I wrote USB HID bootloader and succeeded to erase, program and verify
with PIC32UBL.exe on Windows7. Of course, the application firmware is
no trouble.

However, the latest mphidflash(svn trunk ver.) cannot be used on this
bootloader.

I tried on Mac OS X 10.6.8 and the massage "USB HID device found" is shown
but the process is stopped.

Are there any solution?

*PIC32 bootloader's url
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appn
ote=en554836

Thank,

What steps will reproduce the problem?

1. Get any HEX file which contains a start address record (type 5).  For 
example:
...
:040000051D0040009A
:00000001FF

2. Try to program it into device.

What is the expected output? What do you see instead?

I get a fatal message: Unsupported record type in hex file

What version of the product are you using? On what operating system?

Version: svn checkout revision 7.
Mac OS 10.6.8.

Please provide any additional information below.

Bug fixed, patch attached

HID bootloader hang, when HEX file contains some lines with odd length of bytes 
in line. Adding one byte 0xFF before write data to PIC solve this problem. 

When HEX file contains some code in bootloader memory area or fuses, we must 
skip this area, or unlock fuses. Otherwise verification failed, or attempt to 
write to locked flash program memory hang PIC.

Proposal of version 1.4 is attached. 

Petr

I use PIC24FJ64GB002 and USB Framework v2.7 in Microchip Applications Library.
I wrote the hex of HID Bootloader and I confirmed to be able to wrote 
application hex
with HIDBootloader.exe. The operation is no problem.

Now I think I want to mphidflash on Mac OS X 10.6.3. So I downloaded the latest 
ver.
from SVN and installed.

The writing is maybe OK but the verification is failed. Additionaly an 
application program
doesn't operate.

I attached debug log. Please give me any advice.

Thanks.

What steps will reproduce the problem?
1. mphidflash -r -w <valid hex file>

What is the expected output? What do you see instead?
Blinking LEDs (I used a simple blinking example). Same hex worked written by 
Pinguino-IDE under MS Windows on same device. I didn't try yesterday but I 
think it worked someday with a maybe older mphidflash version under MS Windows

What version of the product are you using? On what operating system?
mphidflash 1.6, Linux Mint 17.2 32bit (Ubuntu deriv, Kernel 3.16.0-38-generic, 
installed libusb versions 0.1.4 & 1.0.0)

Please provide any additional information below.

Target device is a PIC32-PINGUINO-MX220. I tried 2 different ones with same 
result.

What steps will reproduce the problem?
When my HEX file data exactly fills a page (eg 02xx) and jumps to a new 
non-contiguous page (eg 05xx), there is no "Program Complete" USB code 06 to 
make the bootloader flush it's buffer to storage

What is the expected output? What do you see instead?
This results in some sections of storage never being written to

What version of the product are you using? On what operating system?
Running V1.3 on Mac XCODE

Please provide any additional information below.
I've been using mphidflash as a basis for a version that needs no user data, so 
there are more changes.
I also had problems with mphidflash trying to write to invalid data, so I added 
ProgramStart / End bounds - you can delete that code from hex.c.
I added a "flushBuffer" routine, and called it from appropriate places.


Final note: using this on PIC24 family, I also needed to divide all write 
addresses by 2, since the PIC24 uses word addresses but the HEX file uses byte 
addresses! I deleted that code from attached hex.c

What steps will reproduce the problem?

1. save this fragment as mini.hex
:020000040000fa
:020000041fc01b
:042ffc00f7ffff7f5d
:020000040000fa
:020000041fc01b
:080000000010400b000000009d
:020000040000fa
:020000041d00dd
2. build trunk with "-DDEBUG"

3. attempt to program

 USB HID device found
  Device family: PIC32
  Program memory: 512000 bytes free. 
Erasing...
Writing hex file 'mini.hex':Address: 1fc02ffc  Len 4
Writing
Completing
Address: 00000000  Len 8       <------------ ****
Writing
Completing
Address: 1d004000  Len 16
Writing
Completing
PASS 0 of 1 COMPLETE

What is the expected output? What do you see instead?

Inspection of the .hex file shows that it should write 4 bytes @ 1fc02ffc
then 8 bytes @ 1fc00000 then 16 bytes @ 1d004000

In fact, the second write is going to 0x00000000 instead of 0x1fc00000

What version of the product are you using? On what operating system?

trunk latest on Linux.

Please provide any additional information below.

The bug occurs in the handling of type 4 records:

        } else if(4 == type) { /* Extended linear address record */

          if(1 != sscanf(&hexFileData[offset+9],"%04x",&addrHi))
            return ERR_HEX_SYNTAX;
          addrHi <<= 16;
          addr32 = addrHi + addrLo;
          /* Assume this means a noncontiguous address jump; issue block
             and start anew.  The prior noncontiguous address code should
             already have this covered, but in the freak case of an
             extended address record with no subsequent data, make sure
             the last of the data is issued. */
          if(bufLen) {
            if(ERR_NONE != (status = issueBlock(addrSave,bufLen,pass)))
              return status;
            bufLen   = 0;
            addrSave = addr32;
          }

        } else { /* Unsupported record type */


bug 1. addrSave is only updated on a "flush". In the example .hex, there are 2 
adjacent type 4 records. The first one does a flush and sets addrSave to 0. The 
second sets addr32 to  0x1fc00000 but leaves addrSave at 0!! The next data 
record has an address field (low 16 bits of address) of 0 so is considered 
sequential (otherwise addrSave would have been updated and everything would be 
fine). Since it is considered sequential, it is saved ready for writing, but 
using the wrong address: 0

The fix to this is to do "addrSave = addr32" unconditionally.

bug 2. by inspection, "addr32 = addrHi + addrLo;" should be "addr32 = addrHi;". 
An addrLo value is only valid within the context/scope of a type 0 (data) 
record. To consider it another way, that addrLo value belongs with the 
*previous* addrHi. In a pathalogical situation this could cause an address to 
be considered continuous when it is not.

With these two fixes:

Erasing...
Writing hex file 'mini.hex':Address: 1fc02ffc  Len 4
Writing
Completing
Address: 1fc00000  Len 8
Writing
Completing
Address: 1d004000  Len 16
Writing
Completing
PASS 0 of 1 COMPLETE


The patch to fix these both is below:

--- hex.c.orig  2012-07-12 22:05:55.487515965 +0100
+++ hex.c       2012-07-12 22:27:47.048522549 +0100
@@ -308,7 +308,7 @@
              if(1 != sscanf(&hexFileData[offset+9],"%04x",&addrHi))
                return ERR_HEX_SYNTAX;
              addrHi <<= 16;
-             addr32 = addrHi + addrLo;
+             addr32 = addrHi;
              /* Assume this means a noncontiguous address jump; issue block
                 and start anew.  The prior noncontiguous address code should
                 already have this covered, but in the freak case of an
@@ -318,8 +318,8 @@
                if(ERR_NONE != (status = issueBlock(addrSave,bufLen,pass)))
                  return status;
                bufLen   = 0;
-               addrSave = addr32;
              }
+             addrSave = addr32;

            } else { /* Unsupported record type */
              return ERR_HEX_RECORD;


Thanks for a very useful program. I am glad of the opportunity to make it "more 
perfect".

regards,

Neal.

What version of the product are you using? On what operating system?
v1.4


I offer you a commented version, the only code change is to remove unused 
variable ret:

/* check memory address & length are in a programmable memory area, as reported 
by device's Bootloader */
static int verifyBlock( unsigned int *addr, char *len )
{
    int i, isA, isL, MA, ML;
    for ( i = 0; i < devQuery.memBlocks; i++ )
    {
        /* only look at programmable memory blocks */
        if ( !devQuery.mem[ i ].Type ) continue;

        MA = devQuery.mem[ i ].Address;
        ML = devQuery.mem[ i ].Length;
        /* calc if first or last address is in this block */
        isA = ( *addr >= MA ) && ( *addr < MA + ML );
        isL = ( *addr + *len > MA ) && ( *addr + *len <= MA + ML );

        /* loop if neither */
        if ( !isA && !isL ) continue;

        /* both addresses is fine */
        if ( isA && isL ) return 0;
        /* if only start address we adjust length to end of block */
        if ( isA ) *len = ( MA + ML ) - *addr;
        /* if only last address we adjust start to start of block */
        if ( isL ) { *len = ( *addr + *len ) - MA; *addr = MA; }
        return 0;
    }
    /* not programmable */
    return 1;
}

What steps will reproduce the problem?
1. Loading a boot loader with USB access on it using MPLABX & Pickit2. I used 
generic DEMO one from Microchip to compile with a 18f2455 chip set.

2. Placed it in a basic circuit with program & reset capabilities on a 20Mhz 
crystal. Nothing special.

3. Make sure I am root and run the program as rot and load a basic test2.hex
Which only consist of a blinking LED.
./mphidflash -v 2233 -p 7001 -w ../piccode/test2.hex


What is the expected output? What do you see instead?
It does not even get started uploading the test hex file to the pic I get.
 USB HID device found
./mphidflash Error: USB read error

What version of the product are you using? On what operating system?
mphidflash 1.3 : Debian 6.0 stable and Linux Kernel 3.0.8

Please provide any additional information below.
lsusb 
Bus 001 Device 008: ID 2233:7001 RadioShack Corporation 

dmesg
[21964.752426] usb 1-1.4: new full speed USB device number 10 using ehci_hcd
[21964.847784] usb 1-1.4: New USB device found, idVendor=2233, idProduct=7001
[21964.847793] usb 1-1.4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[21964.847800] usb 1-1.4: Product: Generic HID
[21964.847805] usb 1-1.4: Manufacturer: Test
[21964.850760] generic-usb 0003:2233:7001.0005: hiddev0,hidraw3: USB HID v1.11 
Device [Test Generic HID] on usb-0000:00:13.5-1.4/input0

What steps will reproduce the problem?
1. OSX build
2. analyzer
3. run command line

What is the expected output? What do you see instead?

I have a beagle USB analyzer and we tried both the 1.3 and 1.4 (not sure where 
my programmer got that) and a weird thing happens.

The PIC32MX Ethernet Starter kit. Straight 1388 firmware.

The PIC32MX enumerates fine and we start up mphidflash and the code opens and 
finds the PIC32MX HID and then it writes the 02 stream (8 bytes) and the 
PIC32MX never responds.

The Beagle Analyzer file is attached and you can down load the viewer and see 
all the OUTS from the mphidflash program are all in red indicating an error.

What version of the product are you using? On what operating system?

10.8.5

Please provide any additional information below.

Thanks,
Gordon