Wrong _FLASH_ERASE constant for PIC32MX250F128D

[VCC]

Hi,
(@mikroe team)
After playing a bit with the HID mikroBootloader and PIC32MX250F128D, I have found that the loaded user program won't run. The bootloader works ok, but the user program does not start.
The PIC code is the example from compiler folder \Examples\Other\USB HID Bootloader. The source of the problem, I believe, is the _FLASH_ERASE constant, used in Config.mpas. After looking in "PIC32 Flash Programming Specification" document, I found a different constant for _FLASH_ERASE, which makes the bootloader run normally. So, instead of 4096 (4 * 1024), it should be 1024 (4 * 256). I hope this was the right place to look.
Now, the program runs ok.

[filip]

Hi,

Thank you for noticing this, I will report it to our developers and they will solve it as soon as possible.

Regards,
Filip.

[Rotary_Ed]

Thanks much VCC for sharing your find .

With that small change, I too, have now got the HID_USB_bootloader application working between my PC and easyPicFusion v7 board.

Would have never found that myself.

[VCC]

Hi Ed,
please notice the memory allocation chart in the screenshot from my "PIC32 Memory Statistics" application: http://www.libstock.com/projects/view/7 ... statistics. This chart was made from the "faulty" bootloader, where you can see in the first column (Program Flash), that the code does not end up at the end of program flash, instead there is some room for more code. This happens because the whole program starts at an address, multiple of _FLASH_ERASE.

Code: Select all

// Bootloader physical start address equasion:
const BOOTLOADER_START_PHY   = MCU_FLASH_START_PHY+
                               ((__FLASH_SIZE-BOOTLOADER_SIZE) div FLASH_ERASE_BLOCK)*FLASH_ERASE_BLOCK;

So, the number of free addresses (at the program flash end) should be smaller than this constant.

[Rotary_Ed]

Thanks for pointing that out, VCC.

By the way, neat tool! Here is what the my view looks like for the modified USB HID bootloader code with the correct constant compared to the view you posted of the code position with the bad constant.

Bootloader.jpg (217.1 KiB) Viewed 8276 times

Thanks again for the neat tool.

[VCC]

That's interesting. I thought you have problems with 250F128D too. What I say is that the constant is wrong only for 250F128D. My first test was made with 795F512L, and the original bootloader code worked ok with the library constant. I only had to modify the _FLASH_ERASE constant for 250F128D.
The built-in _FLASH_ERASE constant (from the Flash library) should be ok for 795F512L. I don't know why it does not work on your side. Did you adjust the BOOTLOADER_SIZE constant as recommended in nearby comments ?
BTW, if you compare two charts of two different devices (with different memory sizes), you may not see the right difference. At my side, there is some room left to the end of the Program Flash memory for 795F512L bootloader (_FLASH_ERASE is 4096 for 795F512L in the library):

[Rotary_Ed]

No, sorry, I did not realize we were talking about two different classes of chips.

However, I could not get the USB_HID bootloader to work until I change the constant to 1024 in the code, this for the PIC32MX795F512L on my easyPIC Fusion V7 board.

In any case, appreciate you sharing - saved me a lot of time and frustration.

[VCC]

The bootloader should work ok with 4096 for 795F512L. If you align the bootloader at 1024 bytes blocks, it may erase a small part of itself on bigger applications. This is because the erase block for 795F512L is 4096 bytes no matter what you put there. It is hardcoded in silicon. This is why it is important to have the bootloader beginning at an address multiple of _FLASH_ERASE constant. Until your program does not grow enough and does not reach the beginning of the bootloader, you don't have to worry (perhaps the bootloader erases the same block multiple times). However, if you keep the constant at 1024, please be sure to leave at least 4096 bytes between the end of your application and the beginning of the bootloader. However, there must be something different if your code does not work with the default value of 4096.
How about the BOOTLOADER_SIZE constant I mentioned in my previous post ? Is it ok ?
At my side, it is 12977.

Code: Select all

const BOOTLOADER_SIZE: dword = 12977; 

[Rotary_Ed]

Well, after you last post, I went back and switched it back to _FLASH_ERASE constant as opposed to 1024. It compiled fine, but the PC complained that the USB device on the Board was malfunctioning and it would not make contact through the HID tool. I tried several times, but all failed.

I had previously changed the other value you mentioned from 12977 to 16000 (just a guess on my part, but my bootload code appears to be around 1377). For some reason my compiler has stopped reporting memory used after a compile - don't have a clue as to why. It always used to.

I am going to read over the source code and see what I can learn from it

[VCC]

Hi Ed,
here http://www.libstock.com/projects/view/7 ... statistics is a new version (v1.2) of "PIC32 Memory Statistics" application, which can display additional information about memory allocation. You can also filter entries displayed in the two tables or even sort the tables by one of the columns. I hope it can help you with your bootloader.

[Rotary_Ed]

Much appreciate it, VCC. What a great tool.

When I get back to the bootloader, I'll let you know if I find any additional insight.

By replacing the _FLASH_ERASE constant with 1024 as you had pointed out (even if it was a different chip) made the difference, the bootloader works fine with my PIC32 with that change.

One of the reasons I am so interested is that I sell a product that has a software upgradable feature - however, currently it uses USART RS232 (even with an 115200 baud rate) and it can take up to 20 minutes to load the code (Hex file is 250KB). Using the USB HID bootloader, it takes 30 seconds!!!!

Also it will permit using a small micro a/b USB socket in the front of the product (its only 2 1/4" in dia) rather than a d sub 9, so space saved on the front.

Previously, I had used Logic HI to signal a button being depressed and going to the PIC3 chip, I decided to use the more traditional Logic Low to signal a button being depressed. Boy, was that a mistake! I didn't realize how many AND, OR, XOR and CASE/SWITCH statements that would effect in my 25-30K of source code. Still wresting trying to get the same results with some bit logic maniputlation.

Thought I was being smart saving a few traces on the board - would have saved many hours, by just leaving that alone as it worked fine. What is that saying??... oh, yes, "If its not broken, don't try to fix it!"

[VCC]

Hi Ed,
I managed to reproduce part of the behavior you describe regarding the bootloader for 795F512L. When I said the bootloader is working ok for 795F512L with _FLASH_ERASE = 4096, I was partially right, because it worked for a blink LED application. I tried the mikroe's NetEthernet example and it doesn't work ok with bootloader. What's strange is that with _FLASH_ERASE = 1024, a part of bootloader is overwritten so neither the application works nor the bootloader (anymore). With _FLASH_ERASE = 4096, the bootloader is not overwritten.
The board I use is Digilent's Cerebot MX7 cK http://digilentinc.com/Products/Detail. ... EBOT-MX7CK. There are 4 LEDs on this board and all 4 come to get lit, but the server still doesn't respond to pings or http requests. Without the bootloader, it works ok (pings and http requests). Here is the "LEDs part" from the code:

Code: Select all

LED1 := 1;

  Timer1Init();
  InitPHYPins;

  for i := 0 to (NUM_OF_SOCKET_Intern - 1) do
    pos[i] := 0;
    
  LED2 := 1;

  Net_Ethernet_Intern_stackInitTCP();

  LAN8720A_nRST := 0; //Reset
  Delay_ms(1);
  LAN8720A_nRST := 1; //Release Reset

  Net_Ethernet_Intern_Set_Default_PHY;
  Net_Ethernet_Intern_Init(@myMacAddr, @myIpAddr, Net_Eth_Int_AUTO_NEGOTIATION {or {Net_Eth_Int_CUSTOM_MAC} and Net_Eth_Int_DEFAULT_MAC{} ); // init ethernet board
  //Net_Ethernet_Intern_Init(@myMacAddr, @myIpAddr, Net_Eth_Int_FULLDUPLEX or Net_Eth_Int_CUSTOM_MAC or Net_Eth_Int_SPEED_100 {and Net_Eth_Int_DEFAULT_MAC} ); // init ethernet board
  //Net_Ethernet_Intern_Init(@myMacAddr, @myIpAddr, Net_Eth_Int_FULLDUPLEX or Net_Eth_Int_DEFAULT_MAC or Net_Eth_Int_SPEED_100); // init ethernet board

  LED4 := 1;

  Net_Ethernet_Intern_confNetwork(@ipMask, @gwIpAddr, @dnsIpAddr);



  Delay_ms(2000);
  repeat
    //  Process incoming Ethernet packets
    Net_Ethernet_Intern_doPacket();
    //LED4 := 0;
    for i := 0 to (NUM_OF_SOCKET_Intern - 1) do
    begin
      if(socket_Intern[i].open = 0) then
        pos[i] := 0;
    end;
    
    LED3 := 1;
    //LED1 := not LED1;
  until False;

[Rotary_Ed]

There is something not right for sure. My 127K of code bootloaded to the easyPIC Fusion V7 just fine. Did not attempt to see whether all the features of the program functioned, but at least the displays and buttons worked.

I also tried a number of times to create my own bootload code following the instructions in the header of the bootload source code, but while it finally compiled and loaded, the USB HID tool could never detect the bootload code on the board's chip.

Just taking their example and compiling it seems to work OK.