CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

Bootloader problem

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
russk2txb



Joined: 30 Mar 2008
Posts: 109
Location: New Jersey

View user's profile Send private message

Bootloader problem
PostPosted: Wed Jul 11, 2018 6:53 am     Reply with quote

Hi All. I have had a working bootloader for several years, but I just discovered it no longer works. I upgraded the compiler to version 5.071 a while ago so I am wondering if there might be a problem with it. The bootload program hangs the PIC when it tries to write to eeprom. Here is the relevant code:
Code:

if (Bd.addr >= 0xF00000) {
  for (i=0; i < Bd.len; ++i)
    write_eeprom (Bd.addr + i, Bd.data [i]);
}

I should explain that my bootloader does not send the hex file. Instead it converts it to binary and then sends checksummed binary packets. The packets are received into a BootData structure (Bd). After checking the checksum the data is written to the address contained in the structure.

For the PIC4680, EEPROM starts at address 0xF000. All the program code is successfully transferred and written but the loader hangs when it tries to write EEPROM. If the PIC is reset the newly program will run but with the old EEPROM values.

Has there been some change in the way this works - like maybe some need to disable/re-enable some data protection bit. (I think that bit is set automatically when calling the write_eeprom function.)

I should note that the CCSLoad program has no problem writing the EEPROM data.

Thanks for any insight on this,
Regards, Russ
newguy



Joined: 24 Jun 2004
Posts: 1497
Location: Edmonton, Alberta

View user's profile Send private message

PostPosted: Wed Jul 11, 2018 6:56 am     Reply with quote

Remove the #nolist at the top of the processor header file and compile. Do the same for a compiler version that worked, and compare the .lst files. Whatever changed should become apparent.
Ttelmah



Joined: 11 Mar 2010
Posts: 13275

View user's profile Send private message

PostPosted: Wed Jul 11, 2018 7:38 am     Reply with quote

The syntax is 'worrying'. The write_eeprom, function expects an address from 0 to the size of the eeprom, not a value of 0xF00000. That is the address required when using the write_program_memory function to talk to the eeprom....

From the manual:
Quote:

address is the 0 based starting location of the EEPROM write


To work, it'd need:
Code:

if (Bd.addr >= 0xF00000) {
  for (i=0; i < Bd.len; ++i)
    write_eeprom (i, Bd.data [i]);
}


I'd suspect the old function trimmed the address value to an 8bit variable, so was only taking the low byte. The new version may well be using a larger type (is needed for many chips that have larger EEPRROM's).
russk2txb



Joined: 30 Mar 2008
Posts: 109
Location: New Jersey

View user's profile Send private message

Bootloader problem
PostPosted: Wed Jul 11, 2018 10:37 am     Reply with quote

Thanks for the ideas guys. I never noticed that I was sending a 32 bit address to the write_eeprom function. However that was not the problem. To be sure I did change the code to and the address with 0x3FF, but that made no difference. The reason is that the address parameter to the write_eeprom function is 16 bits and so it automatically chopped off those extra bits.

It turns out the problem was not in the boot loader at all. I made a wrong assumption when the Boot host reported a no response error. In fact the problem was that the timeout for the RS232 handler in the PC program had gotten changed (to 100 ms) and that was just too short of a time to write up to 64 bytes to eeprom.

So, thanks again for showing me my error...

Regards, Russ
Ttelmah



Joined: 11 Mar 2010
Posts: 13275

View user's profile Send private message

PostPosted: Wed Jul 11, 2018 11:28 am     Reply with quote

Timeouts. Smile

If I had a cent for every time one has caused me problems I might be worth a few dollars....

The EEPROM is the worst memory here, since while the primary flash does one erase per page, this does erases on a per byte basis.

Glad you found it.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group