| View previous topic :: View next topic |
| Author |
Message |
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
| Usb_bootloader PIC24EP512GU810 (Solved) |
 Posted: Tue Jul 28, 2015 8:36 am |
 |
|
Hello,
I'm working with usb_bootloader but I have a problem.
Processor PIC24EP512GU810
Compiler V 5.046
I plugged in the processor as in the bootloader 'example ex_usb_bootloader.c, I put in my application usb_bootloader.h, compiled generating hex file for my application.
Now turn on the 'hardware containing ex_usb_bootloader.c, and sent him into bootloader by holding down a button,connect the USB plug to the PC, you create a virtual com, I connect with Siow and incio the hex file.
The system starts, charging 7565 lines of 7572 Siow then hangs for timeout.
Using the debug I tried to figure out where it stops and I saw that there is' a block when it must execute the statement | Code: | | read_program_memory (addr, date, count); |
The value of addr is 0x55800 but APLLICATION_END is 0x557FE How can this be?
in ex_usb_bootloader.c | Code: | | line_type atoi_b16 = (& buffer [7]); |
and
| Code: | if (line_type == 1)
done = TRUE; |
indicate the end of data to be sent.
But if you check the hex file (below I put only the 'last part) I do not see any "1" in , here too I do not understand.
| Code: |
:10AFC000000D99003660D500F83500000D99360067
:10AFD000C0AFD20035403400F135C000CA89360018
:10AFE00040466B0036C0B8000F3680007F3D36000B
:10AFF000A0443900376002002A37C000C14C360037
:0200000401F009
:10000800030000FF830000FFE50000FF6F0000FF12
:0C001800300000FF570000FF030000FF55
:00000001FF
;PIC24EP512GU810
;CRC=0A12 CREATED="28-lug-15 16:00"
|
Last edited by Max on Mon Aug 03, 2015 11:46 pm; edited 1 time in total |
|
 |
jeremiah
Joined: 20 Jul 2010
Posts: 1322
|
|
| Posted: Tue Jul 28, 2015 9:08 am |
|
|
Note the 01 before the FF
That is what it is looking for to end the file. |
|
|
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
|
| Posted: Tue Jul 28, 2015 10:36 am |
|
|
| jeremiah wrote: |
Note the 01 before the FF
That is what it is looking for to end the file. |
this is positioned to buffer[8] not [7]
(buffer[0] = ":" ) |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1322
|
|
| Posted: Tue Jul 28, 2015 3:22 pm |
|
|
Yes, but &buffer[7] (points to => "01" ) could be used as a 16 bit input to atoi. I haven't looked at the full code, but I would guess that it what it is doing, since every 2 ASCII digits is a "byte" value when converting.
Remember that while "1" is at buffer[8], "01" starts at buffer[7]. The code you provided suggests it is going for the "01" which is most likely the proper way. |
|
|
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
|
| Posted: Wed Jul 29, 2015 3:02 am |
|
|
ok maybe you're right, but do not get to read it stops before
exactly where to write in program memory line 7565,
or rather when reads
| Code: | | read_program_memory (addr, date, count); |
in order:
addr is 0x000557F0 count is 0x10
| Code: | | write_program_memory(addr, data, count); |
It runs well
It runs well now addr is 0x00055800
| Code: | | read_program_memory(addr, data, count); |
this is not performed, with the simulator (reset and block run) |
|
|
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
| File hex out memory flash |
| Posted: Thu Jul 30, 2015 3:18 am |
|
|
Doing more debugging,
This is due because at a certain point of the hex file contains:
| Code: | 1) : 02000004000AF0 and in the row after
2) :1098300054656C0065666F006E6F00006E756D009C |
in line 1) written above Record type = 4 Extended Linear Address
in line 2) address = 9830
which is outside the flash
in fact ex_usb_bootloader.c hangs on lines
| Code: | write_program_memory(addr, data, count);
addr += count;
read_program_memory(addr, data, count); |
|
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1322
|
|
| Posted: Thu Jul 30, 2015 12:11 pm |
|
|
On my version of PCWHD, the hexfile generated uses addresses that are 2x the actual address (due to how intel hex file format works). Have you verified using the CCS IDE that the addresses are either exactly that you see in the text version or half?
If they are being doubled in the hexfile, then the actual address there would be 0x54C18. |
|
|
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
| Solved |
| Posted: Mon Aug 03, 2015 11:59 pm |
|
|
Dear All,
I solved the problem.
In my source code use many:
| Code: | Rom char *mystring[]=
{
"12345",
"abcde",
"fghil",
".....
}; |
This writes in the latest locations of flash PIC, in my case it seems to depart from the end and then come back.
In this way, at a certain point in the code we will find a "goto" to these addresses.
When using the bootloader of CCS ex_usb_bootloader.c, at some point you will find the instructions:
| Code: | write_program_memory(addr, data, count);
addr += count;
read_program_memory(addr, data, count); |
This is incorrect because
goes out of flash and consequently the next instruction ... hangs across.
I solved this way
| Code: | write_program_memory(addr, data, count);
addr += count;
if(addr < ((int32)APPLICATION_END))
read_program_memory(addr, data, count);
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19328
|
|
| Posted: Tue Aug 04, 2015 12:44 pm |
|
|
Problem is that if you have constant statements that extend right to the top of memory, the top page has it's upper few bytes reserved for the configuration data. If a bootloader wants to update the bytes in this page, it won't work, since as the bootloader can't erase the configuration bytes, the page extends beyond the locations the bootloader can update.
Your fix will stop it failing, but the data in this area won't update properly if an erase is needed.
The better solution if there is enough ROM, is to reduce the top of memory the code uses (#ORG), so that the highest location is a byte below the start of the top page. |
|
|
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
|
| Posted: Tue Aug 04, 2015 2:52 pm |
|
|
Support CCS write
to modify the bootloader:
| Code: |
else if ((line_type == 0) && (addr >= (int32)APPLICATION_START) && (addr < ((int32)APPLICATION_END)))
{
// Loops through all of the data and stores it in data
// The last 2 bytes are the check sum, hence buffidx-3
for (i = 9,dataidx=0; i < buffidx-3; i += 2)
data[dataidx++]=atoi_b16(&buffer[i]);
rom_w_block(addr, data, count);
}
...
.....
rom_w_flush(); |
|
|
|
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
|
| Posted: Thu Aug 06, 2015 8:47 am |
|
|
| Ttelmah wrote: |
The better solution if there is enough ROM, is to reduce the top of memory the code uses (#ORG), so that the highest location is a byte below the start of the top page. |
Hi Ttelmah,
using #ORG and ROM CHAR * name [] ={ "abcd","dfg",..}; option the constant still on the last flash page,
Do you know the directive to manually allocate only the ROM CHAR * ? |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
