mphidflash
mphidflash copied to clipboard
AdamLaurie
mphidflash under Linux not working for Pinguino at least
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.
Original issue reported on code.google.com by [email protected] on 22 Aug 2015 at 2:29
Just tried it with pic32prog. It doesn't work, either. So my installation seems
to be fucked up. Now I "just" have to figure out hat is wrong :-(
Original comment by [email protected] on 22 Aug 2015 at 3:19
Forgot to mention the symptoms: writing destroys the app, but leaves the
bootloader intact. mphidflash does not give an error message, even not for the
verify. pic32prog hangs at verify, but does not give an error message when
verify is turned off. Meanwhile I tried it on MS Windows with mphdiflash v1.3
and the same hex works. I will post the solution here when/if I found it.
Original comment by [email protected] on 23 Aug 2015 at 12:48
I have looked at one version of the Pinguino Bootloader source - https://github.com/PinguinoIDE/pinguino-bootloaders/blob/master/p32/usb/v1.x/main.c
The Bootloader is based on an old version of Microchip's PIC16/ PIC18 /PIC24 Bootloader, so it could be compatible with mphidflash & Microchip's tools.
Except as of the version today, at line 308 we see this handling of the QUERY_DEVICE request:
//****************************************************************************** case QUERY_DEVICE: //******************************************************************************
// Prepare a response packet
PacketToPC.Command1 = (UINT8) QUERY_DEVICE;
PacketToPC.DataSize = (UINT8) DataBlockSize8;
PacketToPC.DeviceFamily = (UINT8) DEVICE_FAMILY;
PacketToPC.Type1 = (UINT8) TypeProgramMemory;
PacketToPC.Address1 = (UINT32) APP_PROGRAM_ADDR_START;
PacketToPC.Length1 = (UINT32) APP_PROGRAM_LENGTH;
PacketToPC.Type2 = (UINT8) TypeProgramMemory;
PacketToPC.Address2 = (UINT32) FCPU;
PacketToPC.Length2 = (UINT32) FPB;
PacketToPC.Type3 = (UINT8) TypeProgramMemory;
PacketToPC.Address3 = (UINT32) USB_MAJOR_VER;
PacketToPC.Length3 = (UINT32) USB_MINOR_VER;
PacketToPC.Type4 = (UINT8) TypeEndOfTypeList;
This request should get a list of programmable memory blocks, however Pinguino sends: Memory Block 1 is the application memory base address & length (as expected), Memory Block 2 is actually the Pinguino's CPU & peripheral clock settings in the memory base & length fields Memory Block 3 is the Pinguino's firmware version.
So Pinguino is sending junk info about the allowed memory areas to program. It is also using the Microchip Vendor ID & the Product ID of the reference Bootloader, which is frustrating (& seems stupid) for detecting the Pinguino & having special handling. Looking at the source code it seems it least the USB strings identify the Pinguino, so if someone did the cross platform code for retrieving the strings it may be possible to identify. As a bonus stupid thing the serial number is hardcoded as 'R.Blanchot' see sd003 definition in usb.c here https://github.com/PinguinoIDE/pinguino-bootloaders/blob/master/p32/usb/v1.x/usb.c (If you can't manage unique serial numbers rather just don't have one.) The simplest thing I can do is just check for rubbish in the response to QUERY_DEVICE, and refuse to program it.
