Real Time Clock Workaround

Hari said:

What is the significance of 0x5C00?

 Hi Harry, this processor (MSP430F5318A) has more than 64K of memory so to address that,  register  extension to more than 16 bit or  banking have to apply.

 Our case is memory banking and addresses from 0 to 0x5c00 are mapped to ram BSL and peripheral, interrupt vector are mapped to usual 0xffxx addresses.

 When you break 64k limit you have to switch bank and jump to new address, so first usable flash address is 0x5c00, i don't know which and why fix code must reside at that address, i hope you can remap to 0x9400 too but read document that say apply this fix. I cannot locate fix code you speak about, are you using an older silicon?

 Regards

 Roberto

Hi Hari,

I think the confusion here is that you are using the F5418 non-A device, and Roberto is talking about the F5418A. The non-A device is the only one that requires this RTC workaround. The F5418 non-A is an older piece of silicon as Roberto mentioned, and if you will look at its product page you will see that in fact it is listed as NRND (Not recommended for new designs) and that we recommend using the F5418A instead if possible. (You may also want to see this document). 

The document that talks about needing this RTC workaround is the same place you'll find a listing of all needed workarounds for your device - the errata for the F5418 non-A. The particular errata that you mentioned is called RTC3 and is listed on p. 29 - it explains exactly what the problem is and why you should use this workaround to fix it. If you decide to switch to the F5418A, please note that this has a separate errata document (many of the errata on the F5418 were fixed in the F5418A). RTC3 does not affect the F5418A.

I hope that this helps clear up the confusion.

Regards,

Katie

Katie Enderle said:

I hope that this helps clear up the confusion.

 Hi Katie, thank for kind and precise answer better than mine, I read the code before your message.

 Hari, I hope your problem is solved, the code is a fix and cannot be moved because is in response to a calling table. If you are still using an older (non A version) silicon code and need help to relocate drop me a message and I try help you.

 Regards

 Roberto

Hari said:

Can you tell me whether the code movement is still possible?

IIRC, the code movement is necessary because the code needs to reside in Bank0 and DWORD aligned. So it is given a fixed start address. it does not need to be this one, bu tsicne it is the start of flash, it is the easiest one to pick. You don't need to know the exact size of the code (which you would need to know if putting it right beneath the interrupt vectors) and won't put a hole in the usable flash space by placing it somewhere in the middle of the first flash bank.
The address has no other magic than being the lower edge of the flash space in the lower 64k of the address space. So if you really need to put it somewhere else, do so, as long as it is in the lower 64k and DWORD aligned (lowest 2 bits of the starting address are 0)