AWR1642: Bootloader failing to load some firmware images on GP and HS 2.0 devices

Hi,

Have you tried a similar boot on a non-secure part?

Thank you
Cesar

Yes, I have. It had the same issue.

Thanks,

Erik

Hi Erik,
Can you make sure that non-woking application doesn't have any loadable section to native MSS TCMB (0x0800 0000)? AWR1642 bootloader doesn't support to load any application to TCMB as bootloader might be running some of it's part from TCMB (const, sysHeap etc.).

Could you provide the detail of code change you are doing on top of working application which is causing failure to load the metaImage?


Regards,
Jitendra

Thanks Jitendra, 

Reviewing the MSS memory map output, I made sure there are no "const" or "code" descriptions on anything stored in the 0x0800 0000 memory region. Is there a better way to determine if something is considered "loadable"?

The code changes are typically adding additional code to the MSS. For example, doing a diff between a bootable and non-bootable MSS memory map output, I notice the following two items:

1. The memory region from 0x0800 0000 and higher is identical between the two memory map outputs
2. The "used" portion of PROG_RAM goes from 0x000283be (bootable image) to 0x00028446 (non-bootable image).

Thanks,

Erik

Hello Erik,
If I refer mmw demo mss map file -
1. All the content/section which goes to DATA_RAM [0x08000000] should be UINITIALIZED
2. In the LINKER GENERATED COPY TABLES, these memory should have load address intial around PROG_RAM but run address to DATA_RAM.

Even I have tried adding much code in MSS on top of mmw demo but I don't see ay issue for flash bootup.


Regards,
Jitendra

Thanks Jitendra,

Jitendra Gupta said:

1. All the content/section which goes to DATA_RAM [0x08000000] should be UINITIALIZED

All of the content does say "UNINITIALIZED" for the DATA_RAM

Jitendra Gupta said:

2. In the LINKER GENERATED COPY TABLES, these memory should have load address initial around PROG_RAM but run address to DATA_RAM.

All of our "load addr=" all starts somewhere within PROG_RAM and all our "run addr=" is somewhere within the DATA_RAM. 

Our project is based off of the mmw demo as well; not much has changed with the linking process. Is there anything else that could cause issues during flash bootup?

Thanks,

Erik

Hi Erik,
Are you using secondary bootloader application (SBL) to load this modified application to the device from sFlash?
I assume bootloader you mentioned in the last post targetted to primary bootloader of the device.

Regards,
Jitendra

Hi Jitendra,

We are not using a secondary bootloader to load the modified application to the device from sFlash. We are relying on the primary, serial bootloader to load the application from flash.

For this testing, I've been using Uniflash to flash the new application. I've also dumped the entire image from flash, over serial (For this test, I used a backup image to read from flash). The data in flash matches the image generated by Code Composer, byte-for-byte, yet, it still will not boot successfully. 

Thanks,

Erik

Hi Erik,

The first two points in your original post under "Details" makes me think it might not be a bootloader issue, but rather an MSS issue. What happens if you take the failing executables and load/run them in CCS? I would try starting one core at a time, and again by grouping the cores so that they start at the same time (as they would when run from flash). If there's an issue that causes a core to assert early, the program will appear dead. Loading from CCS will point out if a core has exited.

-dave

Hi Dave,

From my understanding, if the MSS asserts, the primary bootloader won't attempt to load another application. When the MSS asserts or crashes in my experience, the system is effectively hung and is unrecoverable until power cycling or resetting the processor. Is this a correct understanding?

In our case, there are two images/applications programmed into sFlash. What I suspected was happening, is the primary bootloader finds an issue with the image in the first slot and skips it. It will then move to the second meta image slot and attempt to load our backup image, which then loads successfully. If there is not a backup image present, and only the failing executable is present, the nError LED goes on, which I realize can be for a number of reasons, but one of them is a failure to successfully boot from an image.

Unfortunately, we currently don't have access to a 2.0 board we can debug through CCS. We have a 1.0 device we can run through CCS without problems, but that's using the SDK v1.x which isn't really the best comparison.


Thanks,
Erik

> Is this a correct understanding?

Correct, the bootloader would not transfer control to the application if it didn't load correctly. But the fact that you can make changes to the MSS image and it is then successful indicates an issue with the MSS - perhaps the image itself.

You are using SDK 2.0. Are you building within a CCS project or using makefiles? Are there any linker warnings or suspicious compiler warnings? Have there been changes to the linker .cmd files, or the "post build" tool commands that create the meta-image .bin file from .xe674 and .xer4f? Perhaps you could post the MSS' .map file for a failing build? (just the first part, up to the section allocation map).

Thanks, dave

Thanks Dave,

db_woodall said:

Are you building within a CCS project or using makefiles?

We are building within CCS. Yes, this is SDK v2.0

db_woodall said:

Are there any linker warnings or suspicious compiler warnings?

There are no linker warnings or compiler warnings. We do have "Optimization Advice"  to increase our compilation optimization level, but we have never changed that and would like to maintain that compilation level for now.

db_woodall said:

Have there been changes to the linker .cmd files

We have not changed the linker files for the MSS

db_woodall said:

the "post build" tool commands that create the meta-image .bin

We have not changed the "post build" tool commands to create the meta-image. We have added additional post build steps to build an additional image, our high security image. But, we have not changed previous steps.

db_woodall said:

Perhaps you could post the MSS' .map file for a failing build? (just the first part, up to the section allocation map).

I will get back to you on this item. We would prefer to securely share this information with you.

Thanks,

Erik