TMS320F280039: Need some suggestions on customized LFU

please note most of the team is OOO due to the US holiday.  Please expect a response next week.

Hang,

1. For version, typically we have used a decrementing approach since erased Flash is FFFF. However, this is purely for illustration purposes. Customers really have to decide on a versioning scheme and go with it. Why does the cmd file need to change depending on the version? I agree they need to have separate cmd files for different banks.

2. In our LFU example, on an LFU command from the host, execution will switch from the App to the Bootloader. However, interrupts will still be enabled. This means that whenever interrupts occur, ISRs from the App execute. During idle time, execution falls back to the Bootloader. This is consistent with what you have described above. ISR context save is done in software by the C compiler, so the user does not need to take any special steps here. (unless the user has written some assembly code ISRs, in which case they would need to follow the necessary context save and restore steps).

The part that our LFU example doesn't address is the "bootloader error" you refer to. So we have just one bootloader in our Flash. I would like to understand under what context there could be a bootloader error following which you need to return to the App. I can understand the possibility of errors during a bootloader upgrade, and therefore the need for a backup/default. As long as the bootloader upgrade and the app upgrade are done separately, I don't see an issue.

Thanks,

Sira

Hi Sira,

To Clarify their use case:

Why does the cmd file need to change depending on the version?

-> For example, the device is now having bootloader on bank 0, app v1.0 on bank1 and app v1.1 on bank2. At this point, they would like to make app v1.2 on top of app v1.1. Note that app v1.2 should go to bank1, overwriting app1.0, because if the LFU to app1.2 fails, for example, due to a connection lost, the app1.0 would be corrupted and the device should run app1.1 as backup. Since app1.2 is modified based on app1.1, so it uses a bank2 cmd, and they need to change to bank1 cmd. Same process occurs when making app1.3 from app1.2. 

ISR context save is done in software by the C compiler, so the user does not need to take any special steps here

-> I agree that user doesn't not need wo worry about context saving for ISR, but how about the app background? If the app uses a LB instruction to switch to bootloader, after bootloader done its job, how should the bootloader switch back to app, but with the app executing the line right after LB instruction instead of from the app entry?

 "bootloader error"

-> Asking customer for this detail 

Regards,

Hang.

Hang,

Yes, alternate versions will use alternate linker cmd files, this is understood. But there is no additional relationship between the "exact version name" and the linker cmd file. As long as the alternate versioning relationship is maintained with the linker cmd file, things should be fine.

Yes, you will use an LB to branch from the app to the bootloader, and likewise, you will use an LB to branch from the bootloader to the new app (the LFU entry point). This is well illustrated in TIDM-02011.

Thanks,

Sira

Hi Sira,

After branch to bootloader from app, in some scenario （for example the new app is not completly downloaded） they need to branch back to the same app, and carry on the previous job before branching to app. To achieve this, they need to design some sort of context saving so that when bootloader branch to app, it branch to the place where the app was running before branching to bootloader., instead of branching to the app entry, right? That would like to avoid designing this context saving mechanism.

Regards,

Hang.

Hang,

You can use a LCR instruction instead of an LB instruction in that case, and a LRETR instruction to return. That will cause it to return to the same location from where it branched. You can refer to spru430f.

Thanks,

Sira

Hi Hang,

the TI linker has an integrated preprocessor, that probably could be used, to change the application start address, based on the version, if the version is passed to the linker. Alternatively, you could build the firmware for both banks (having two linker scripts). This would allow you, to use every bank for every firmware version. You would have to implement some protocol, to pick the bank with the oldest version.

For your second question: What, if you implement the upload and storage of a new firmware in the application itself? After uploading the second bank, the uploaded image could be checked and then the application could be restarted by invoking the bootloader.

If you really have to save the context of the firmware, then you would also have to transfer the context of one version of the firmware to new version of the firmware. If that is not required, then I could not see, why this should be a requirement for the rare case, that a firmware upload failed.

If you really want to save the state of your firmware and have it loaded by a firmware with a different version, you should think about having some kind of versioned ram data base for firmware state.

best regards,

Torsten