PIC32 bootloader

[mpavlica@gmail.com]

Moving topic here.

I would like to ask mE team to check this two projects, or maybe should I open a ticket on a support?
Project with 795 PIC compiles with no problems.
when I switch to PIC32MX170F256D it returns "not enough ROM" which is not true.
Please check if there might be some problems with defs files for PIC chips used.
Since I am from Serbia, I can easily deliver PIC chip for testing.

Kindest regards!

[VCC]

Hi,
probably you've copy-pasted the project and changed the device only. As I can see from project settings, both projects have the EBase address set to 9FC01000. Please create a new (empty) project, from scratch with PIC32MX170F256D and let the IDE set the EBase for you. Copy that value and set it to the existing bootloader project. That might fix the issue.

[mpavlica@gmail.com]

Nope, I was thinking about that too, still the same problem... Now even throws another error too!

[VCC]

Same old problem, the definition files contain wrong constants:

in mpas file, you have to set:

Code: Select all

const __BOOT_FLASH_SIZE : dword = 0x00000BF0;

in mlk file, you have to set:

Code: Select all

	<ROM>
		<MIN_ADDR>0x1D000000</MIN_ADDR>
		<MAX_ADDR>0x1D03FFFF</MAX_ADDR>
	</ROM>

[mpavlica@gmail.com]

I did it now, and still.... Not enough ROM space... Probably there are more errors in defs files... mE team???

[VCC]

There are many calculations for addresses and sizes, which used to work. I don't know now if they are still valid.
For example,
in bootloader_user.mpas, there is USER_BOOTLOADER_SIZE
in bootloader_common.mpas, there is USER_BOOTLOAD_ADDRESS

Usually, the calls to SetOrg (see bootloader_core.mpas) will cause "Not enough ROM space" error.

[mpavlica@gmail.com]

Yes, I did try to increase USER_BOOTLOADER_SIZE because i dont know what will be size of a bootloader afetr compiling, but still reports same error... Any ideas for a workaround?
And yes, firs error occurs wit OrgAll...

[VCC]

I'll kind of give up for now, as I have to work on some other stuff. If you leave this to mikroe and they don't respond next week, you may have to create a new thread, where others don't respond. Otherwise mikroe think(s) the thread is "handled" and won't look at it.

[mpavlica@gmail.com]

I will probably open a ticket. Thank you for trying anyway. If you might be able to help later, i would appreciate that. I do understand that this bootloader is made to be universal, but I would mind if it is hardcoded just for this type of PIC chip. Thanks anyway.

[VCC]

So.. I was a bit wrong about letting the IDE fill in the EBase value. If you set it to 0x9FC00000 in ProjectSettings, the project can be compiled.
Also, the calculations from bootloader_core.mpas seem fine.

There is one more thing I had to change. It was the code size, from the USER_BOOTLOADER_SIZE constant (in bootloader_user.mpas). I set it to 3780. The reported size after compilation is 3771.

[mpavlica@gmail.com]

GREAT!
I can compile code now. Moving on, now it responds to PC software, sends all bootinfo data but software on PC side doesnt parse that information... moving on slowly...

[VCC]

I remember having to set UART baud rate to 256000, both on PIC side and on PC side. That was the highest baud rate available on FT232R.

[mpavlica@gmail.com]

OK, this is what i get on the software - screen 1 2 3 are showing what locations are programmed

bootloader loading 1/3

Screen1.jpg (464.66 KiB) Viewed 1242 times

bootloader loading 2/3

Screen2.jpg (600.57 KiB) Viewed 1242 times

bootloader loading 3/3

Screen3.jpg (570.13 KiB) Viewed 1242 times

[mpavlica@gmail.com]

Screen 4 is how hex file is parsed

Screen4.jpg (61.29 KiB) Viewed 1241 times

Screen 5 is what happens if i burn loader without boot write protection enabled. it stops and then doesnt return until i reflash PIC.

screen5.jpg (151.58 KiB) Viewed 1241 times

Any suggestions? Is EBASE address wrong?
Also i am attaching project that is current version....

[VCC]

Hi,
I made a comparison between openMikroBootloader and HIDBootloader. They both seem to be doing the same thing. See attached screenshots. The only differences are a few addresses, as expected.


Edit (a bit of progress):
what I've failed to notice before, is that the desktop application is sending a command, to erase (and then overwrite) the last page, which includes the configuration bits:

ErasingCFGBits.png (55.97 KiB) Viewed 990 times

.
Edit2:
a quick and ugly fix, to avoid overwriting the CFG bits, is to verify their addresses, before calling Flash_Erase_Page and Flash_Write_Word.
So, in bootloader_mcu.mpas, modify like this:

Code: Select all

procedure Bootloader_Mcu_EraseFlash(var Address: DWord);
{$IFDEF P30}
var
  i: Integer;
  TempAddress: DWord;
  Temp: array[USER_BOOTLOADER_ERASE_BLOCK] of Byte;
{$ENDIF}
begin
  {$IFDEF USER_DEBUG}LongWordToHex(Address, s1);SendDebugStr('Erase Address Before: 0x' + s1);LongWordToStr(USER_BOOTLOADER_ERASE_BLOCK, s1);SendDebugStr('Erase Blocksize: ' + s1);{$ENDIF}
  {$IFDEF P32}
    //if Address < ...... then //for PIC32MZ (to be verified if all have the same address)
    //if Address < ...... then //for PIC32MX795F
    //if Address < $1FC00800 then //for PIC32MX170F/270F
    if Address < $1FC00000 + __BOOT_FLASH_SIZE - _FLASH_ERASE then  //for  PIC32MX270F   ///////////////////////////////////////////// 1FC007F0
      Flash_Erase_Page(Address);
    
    Address := Address + USER_BOOTLOADER_ERASE_BLOCK;                           // 4 Bytes per instruction, 4 Addresses per instruction
  {$ENDIF}

Code: Select all

procedure Bootloader_Mcu_WriteFlash(var Address: DWord; ByteCount: DWord; DataPtr: PByte);
var
  i: DWord;
  DoubleWordArray: array[2] of DWord;
begin
  {$IFDEF USER_DEBUG}LongWordToHex(Address, s1); SendDebugStr('FlashWrite Address: 0x' + s1);LongWordToStr(ByteCount, s1); SendDebugStr(', ' + s1 + ' bytes ');LongWordToHex(DataPtr, s1); SendDebugStr('Data Address: 0x' + s1);SendDebugStr('[');for i := 0 to 11 do begin ByteToHex(PWriteByteDataArray( DataPtr)^[i], s1);SendDebugStr('0x' + s1);end;SendDebugStr(']');{$ENDIF}
  i := 0;
  while i < ByteCount do                                                      // PIC33 192 Bytes per Instruction
  begin
    {$IFDEF USER_DEBUG}LongWordToStr(i, s1);SendDebugStr('ByteStart: ' + s1);{$ENDIF}
    {$IFDEF P32}
      // This can only write 1 Instruction at a time so fixed values are used.
      // The MCU may require a larger write number than 1 in order to actually
      // write all the latches.  This is handled by setting USER_BOOTLOADER_WRITE_BLOCK to
      // that value and the loop calls this multiple times
      
      //if Address < $1FC0FF40 then //for PIC32MZ (to be verified if all have the same address)
      //if Address < $1FC02FF0 then //for PIC32MX795F
      //if Address < $1FC00BF0 then //for PIC32MX170F/270F
      if Address < $1FC00000 + __BOOT_FLASH_SIZE then  //for  PIC32MX  /////////////////////////////////////////////
        Flash_Write_Word(Address, PDWord( DataPtr)^);
      
      Address := Address + 4;                                                   // 1 address per 4 bytes
      DataPtr := DataPtr + 4;                                                   // 1 instruction per 4 bytes
      i := i + 4
    {$ENDIF}

A proper fix would be to change some logic in the desktop app.
Still, this fix is not enough. Now the loading stops at writing the first block of data (at 0x1D0000000).