TMS320F280039C: Processor options issue about --lfu_reference_elf=path

Hi Bruce,

I am not familiar with the issue, but can talk to others regarding this. 

Seeing as the lfu_reference_elf is a part of CCS, I can look into the internal support for this.

Thanks and regards,

Charles

Hi Charles,

Thanks! Looking forward your feedback!

Bruce,

"I looked at the data at 0x00000000 in the memory, and found that the program data with the reference image added and the program without the reference image are the same when it is burned in. "

What does the above mean? Assuming your reference image is on Bank0, and your new image is on Bank1, are you saying the Flash Bank1 contents are the SAME whether or not the Bank1 image is built with lfu_reference_elf specified or not?

If this is the case, then it seems like something is not right, because including the reference image tells the compiler which global variables etc. are common between the Bank0 and Bank1 firmware versions, and therefore that will reflect in the Bank1 contents.

Additionally, What is the difference between your Bank0 and Bank1 firmware?

"Once running, this part of the program that adds reference images changes a lot, and changes all the time."

I did not understand what this means. Can you explain?

"The data of this part of the program without adding the reference image remains unchanged."

I did not understand what this means. Can you explain?

"One thing I would like to confirm is that  --lfu_reference_elf=path is to obtain a list of the memory addresses of global and static symbols, why it modify address 0x0000-0x0800 and 0x0D00-0x0EFF?(The address of data change is fixed)"

Those are M0/M1 RAM addresses, and Interrupt Vector Table addresses. 

If the Bank1 firmware changed the interrupt vector table, that's one possibility. Or if the interrupt vector table SWAP feature was used, that's another possibility.

M0/M1 RAM contents may have changed based on how Bank1 firmware uses M0/M1 RAM.

Hi Sira,

Sira Rao80 said:

What does the above mean? Assuming your reference image is on Bank0, and your new image is on Bank1, are you saying the Flash Bank1 contents are the SAME whether or not the Bank1 image is built with lfu_reference_elf specified or not?

If this is the case, then it seems like something is not right, because including the reference image tells the compiler which global variables etc. are common between the Bank0 and Bank1 firmware versions, and therefore that will reflect in the Bank1 contents.

Additionally, What is the difference between your Bank0 and Bank1 firmware?

Yes, my reference image is on Bank0, and new image is on Bank1. There is no difference between Bank0 and Bank1 firmware except linker command file.

Sira Rao80 said:

Those are M0/M1 RAM addresses, and Interrupt Vector Table addresses. 

If the Bank1 firmware changed the interrupt vector table, that's one possibility. Or if the interrupt vector table SWAP feature was used, that's another possibility.

M0/M1 RAM contents may have changed based on how Bank1 firmware uses M0/M1 RAM.

I checked the code and found SWAP is not used.

Regarding changed the interrupt vector table, we use Interrupt_initVectorTable() in the firmware, will this have any impact?

In addition, I need to add some details: the code we created to add a reference image can run normally after a jump, but the new firmware cannot be started after powering on and off again. Besides, we changed this program from coff to eabi. Will this have any impact?

So when you do Live Firmware Update it works properly and transitions to the new FW, but when you power cycle it does not boot up the new FW properly? Is that when the  "found that the program stuck between 0x00000000 and 0x3FB8B9" issue occurs?

I don't know many details about the design, so it is hard to guess what the issue might be.

Have you/the customer looked at our TIDM-02011 LFU reference design and understood the flow details there?

Sira Rao80 said:

So when you do Live Firmware Update it works properly and transitions to the new FW, but when you power cycle it does not boot up the new FW properly? Is that when the  "found that the program stuck between 0x00000000 and 0x3FB8B9" issue occurs?

Yes, your understanding is correct.

Sira Rao80 said:

Have you/the customer looked at our TIDM-02011 LFU reference design and understood the flow details there?

The customer's design is based on 02011. Maybe we can have a meeting with customer to discuss?

Bruce, that may help. I will be out of office next week until Thursday. Can you set up a meeting for Thursday? What timezone is the customer in?

Hi Sira,

Thanks, I'll discuss with you on Webex.

Sounds good.