This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28388D: Tms320f28388 custom bootloader/kernel for CM core

Part Number: TMS320F28388D

We are working on developing Bootloader for upgrading the firmware over Ethercat protocol using TMS320f28388d development board. We have referred the document “spruiu8a_lfu” provided by TI for live firmware update.

As per the document "spruiu8a_lfu" i am applying same procedure for all cores means divided flash memory for kernel and application in all the cores. Initial 3 sectors are reserved for the Kernel and the remaining sectors is for application.

Iam able to achieve both kernel and application working for CPU1 and CPU2 cores as per the document "spruiu8a_lfu". But for CM core it is not working.

In the CM core the kernel is loaded an application and when it invokes the application the application is not running and getting struck in some address.

So, I request to, please go through the below steps followed and suggest if any mistake is being done suggest any method.

Here Bootloader/ kernel is placed in the first four sectors of flash memory and start executing at the default flash boot address 0x00200000.

The Application code is placed in the rest sectors of the flash memory and start executing on the Alternate flash address 0x00250000.

Tha Bootloader/ kernel is programmed using CCS, after every power reset, the bootloader/kernel code starts executing at the default flash address 0x00200000 and looks for the key 0x5A5A5A5A stored in the end of the third sector. If the kernel finds the key, then it assumes that the Application is programmed already into the flash, and it calls the entry address of the application code as

asm(" mov r12, #0x250000");
asm(" blx r12");

IF the kernel does not find the key, then it assumes that no Application code is present in the flash memory and it waits for user input to programmer the application code into the flash memory, after the programming it writes KEY value 0x5A5A5A5A into the end of kernel flash sector.

Here the Problem we are getting is , Once the kernel finds the key and calls the application using assembly instruction asm(" mov r12, #0x250000");
asm(" blx r12");
 the code is not getting executed and staying at the reset vector.

Here I have verified about the memory regions allocated and the generated after compiling I didn’t find any issue and there is no overlapping between kernel and the Application. 

So, requesting to please suggest any way to resolve this, your help will be appreciated lot.

Iam generating bin file using "armHex.exe" utility using the command below

" armhex.exe -boot -gpio8 -b -o BTDC_Proto_CM.bin BTDC_Proto_CM.out "

Please find the .cmd file attached for Kernel and Application also the Kenel pseudocode is attached here.

The Application .bin file is attached here.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CM Kernel memory Configuration file
----------------------------------------------
MEMORY
{
/* Flash sectors */
CMBANK0_RESETISR : origin = 0x00200000, length = 0x00000008 /* Boot to Flash Entry Point */
CMBANK0_SECTOR0_1_2 : origin = 0x00200008, length = 0x0000BFF7
/* CMBANK0_SECTOR1 : origin = 0x00204000, length = 0x00004000 */
/* CMBANK0_SECTOR2 : origin = 0x00208000, length = 0x00004000 */
CMBANK0_SECTOR3 : origin = 0x0020C000, length = 0x00004000
CMBANK0_SECTOR4 : origin = 0x00210000, length = 0x00010000
CMBANK0_SECTOR5 : origin = 0x00220000, length = 0x00010000
CMBANK0_SECTOR6 : origin = 0x00230000, length = 0x00010000
CMBANK0_SECTOR7 : origin = 0x00240000, length = 0x00010000
CMBANK0_SECTOR8 : origin = 0x00250000, length = 0x00010000
CMBANK0_SECTOR9 : origin = 0x00260000, length = 0x00010000
CMBANK0_SECTOR10 : origin = 0x00270000, length = 0x00004000
CMBANK0_SECTOR11 : origin = 0x00274000, length = 0x00004000
CMBANK0_SECTOR12 : origin = 0x00278000, length = 0x00004000
CMBANK0_SECTOR13 : origin = 0x0027C000, length = 0x00004000
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CM Application memory configuration file
-----------------------------------------------------------
MEMORY
{
/* Flash sectors */
CMBANK0_RESETISR : origin = 0x00250000, length = 0x00000008 /* Boot to Flash Entry Point */
CMBANK0_SECTOR0_1_2 : origin = 0x00200000, length = 0x0000BFFF
/* CMBANK0_SECTOR1 : origin = 0x00204000, length = 0x00004000 */
/* CMBANK0_SECTOR2 : origin = 0x00208000, length = 0x00004000 */
CMBANK0_SECTOR3 : origin = 0x0020C000, length = 0x00004000
CMBANK0_SECTOR4 : origin = 0x00210000, length = 0x00010000
CMBANK0_SECTOR5 : origin = 0x00220000, length = 0x00010000
CMBANK0_SECTOR6 : origin = 0x00230000, length = 0x00010000
CMBANK0_SECTOR7 : origin = 0x00240000, length = 0x00010000
CMBANK0_SECTOR8 : origin = 0x00250008, length = 0x0000FFF8
CMBANK0_SECTOR9 : origin = 0x00260000, length = 0x00010000
CMBANK0_SECTOR10 : origin = 0x00270000, length = 0x00004000
CMBANK0_SECTOR11 : origin = 0x00274000, length = 0x00004000
CMBANK0_SECTOR12 : origin = 0x00278000, length = 0x00004000
CMBANK0_SECTOR13 : origin = 0x0027C000, length = 0x00004000
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CM kernel Pseudocode
----------------------------
void main(void)
{
/* initialize the Hardware and the EtherCAT Slave Controller */
if((HWREG((uint32_t)B0_KEY_ADD) != (uint32_t)KEY))
{
HW_Init();
MainInit();
IPC_sync(IPC_CM_L_CPU1_R, IPC_FLAG31);
//BTDC_EthernetInit(); // commented this sice Ethernet is not required for Kernel code
/* Added by Rajkumar */
//
// Initialize the stack FoE functions to enable FoE functionality
//
tiesc_foe_init();
//
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CM Application .bin file
-------------------------------------------
08 aa 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 26 6c 4d 00 06 00 25 00 00 16 f0 24 be
70 47 01 40 00 25 10 00 50 18 00 20 01 00 25 00
9f 04 26 00 ff cf 25 00 27 b6 25 00 27 b6 25 00
27 b6 25 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 27 b6 25 00 27 b6 25 00 00 00 00 00
27 b6 25 00 27 b6 25 00 27 b6 25 00 27 b6 25 00
27 b6 25 00 27 b6 25 00 27 b6 25 00 27 b6 25 00
27 b6 25 00 27 b6 25 00 27 b6 25 00 27 b6 25 00
27 b6 25 00 27 b6 25 00 27 b6 25 00 b1 ae 25 00
d7 68 26 00 27 b6 25 00 d7 68 26 00 27 b6 25 00
27 b6 25 00 27 b6 25 00 27 b6 25 00 27 b6 25 00
27 b6 25 00 27 b6 25 00 27 b6 25 00 27 b6 25 00
27 b6 25 00 27 b6 25 00 27 b6 25 00 27 b6 25 00
27 b6 25 00 27 b6 25 00 27 b6 25 00 27 b6 25 00
27 b6 25 00 27 b6 25 00 27 b6 25 00 27 b6 25 00
27 b6 25 00 27 b6 25 00 27 b6 25 00 27 b6 25 00
27 b6 25 00 27 b6 25 00 27 b6 25 00 27 b6 25 00
27 b6 25 00 27 b6 25 00 27 b6 25 00 27 b6 25 00
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi Rajkumar,

    I'll be able to look into your inquiry within the next day.

    Thanks and regards,

    Charles

  • Thank you very much charles,Looking for suggestion.

    Also i have attached an video to show the flow of execution in the CM core.Please check this.

  • Hi Rajkumar,

    When jumping to the application in CCS, can you load the symbols for the application?

    For the asm lines to branch to the application, can you try to place the lines within a subfunction?

    Thanks and regards,

    Charles

  • Thank you charles,

    I will do that and send you the details, but did you check whether iam following the right procedure, especially generating the bin file and invoking the application from the kernel, is that ok?

  • Rajkumar,

    Conceptually what you are doing is correct (same as what's done on CPU1/CPU2 - good to know it's working there).

    1. If you program the Application memory space using CCS (not the bootloader), and then try to run it, does it work? In this case, you may need to disable the KEY check since it won't be written. But this would be a first step in validating the branching from the bootloader to the App.

    2. If above works, export out contents of Application memory into a file, and compare whether there's a match between when you use the bootloader to program the Application, and when you use CCS to program the Application. If there's a match, it means your bootloader is good, and we can look at other possibilities. If there isn't a match, it means your CM bootloader has some issue.

    Thanks,

    Sira

  • Thank you very much Sira,

    please find my reply as below:

    1. If you program the Application memory space using CCS (not the bootloader), and then try to run it, does it work? In this case, you may need to disable the KEY check since it won't be written. But this would be a first step in validating the branching from the bootloader to the App.

    Rajkumar:Yes i have tried this, Its working.

    2. If above works, export out contents of Application memory into a file, and compare whether there's a match between when you use the bootloader to program the Application, and when you use CCS to program the Application. If there's a match, it means your bootloader is good, and we can look at other possibilities. If there isn't a match, it means your CM bootloader has some issue.

    Rajkumar:Yes i have tried this, Both the data are matching.

    What do you think the issue?

  • Thank you charles and Sira,

    please find the video which shows, loading the symbols of application during the call of application from bootloader.

    and i found that, after loading symbols it is working, but when i call it from the bootloader it is not working. Request to Please go through the below video and suggest.

  • Thanks for confirming Rajkumar. Please give me sometime to review your video and get back to you.

  • Hi Sira,

    I want to recheck for one of your questions

    1. If you program the Application memory space using CCS (not the bootloader), and then try to run it, does it work? In this case, you may need to disable the KEY check since it won't be written. But this would be a first step in validating the branching from the bootloader to the App.

    Ans: No, it's not work through kernel bootloader and also using ccs both of them has same behavior. 

    So far According to Raj Kumar Testing your seeing two videos one without application symbols and other with application symbols loaded.

    Test using Debugger with Loaded Application symbols:

    One which most recent video uploaded by raj Kumar. In this case when App symbols loaded the debugger considering it as separate project, so it is starting from resetisr (0x250000). so, no transition happening from kernel to application. This is the reason you can see application is running. Correct me if Iam wrong this is my observation.

    Test using Debugger without Application symbols:

    Refer to first vedio. Now after blx #0x250000 pc is loaded with 0x250000. and instruction at 0x250000 starts executing you can find the snippet below. after this the next instruction should be the cint00_args(0x266c4c).

    But here during execution of instruction or before execution of instruction an exception is raised and PC points to 0x000041c4. attaching the snippet.

     Highlighted the registers.

    So, this exception is not raised when debugged with loaded application symbols. Just finding what exception it is and referring the trm manuals but hard to find and why it causes. Exception number is 000000011.

    Also, I see the stack in app and kernel points S0RAM both has same address (is this not an overlap?). And kernel .sysmem and app .bss points to same address. will these have no impact?

  • Sravan, Rajkumar,

    1. Use CCS and program the application to the CM Flash. Does this work?

    2. Use CCS and program the application to the CM Flash. Load the application's symbols. This works. Correct? (this part is confusing to me since you have already loaded the application using the debugger/emulator, so the act of loading symbols is redundant here).

    3. Use the Flash Bootloader and program the application to the CM Flash. This does not work. Correct?

    4. Use the Flash Bootloader and program the application to the CM Flash. Load the application's symbols. Does this work?

    5. What is at 0x00250000?

    6. Please send the exported contents of CM Flash when programmed using CCS and when programmed using the Flash bootloader.

    Thanks,

    Sira

  • Good Morning Sira,

    please find the responses below.

    1. Use CCS and program the application to the CM Flash. Does this work?

    Rajkumar: Yes, This works. Please check the below attached video for your reference.

    2. Use CCS and program the application to the CM Flash. Load the application's symbols. This works. Correct? (this part is confusing to me since you have already loaded the application using the debugger/emulator, so the act of loading symbols is redundant here).

    3. Use the Flash Bootloader and program the application to the CM Flash. This does not work. Correct?

    Rajkumar: Yes, with this method it is not working, please find the below attached video for your reference.

    4. Use the Flash Bootloader and program the application to the CM Flash. Load the application's symbols. Does this work?

    Rajkumar: Here I found some it is working, but Iam not sure Iam following correct steps on this, i will recheck and confirm you.

    5. What is at 0x00250000?

    Rajkumar: This is the starting address for Application, nothing but reset address for application and the value stored is as given in the below image.

    6. Please send the exported contents of CM Flash when programmed using CCS and when programmed using the Flash bootloader.

    Rajkumar: i have compared both data are same. Please find the below data for your reference.

    ApplicationThroughCCS1.txtApplicationThroughBootLoader1.txt

  • Hi Sravan,

    Based on Table B1-4 in the ARMv7-M Architecture Reference Manual, the exception occurring in the above screenshots indicates a HardFault Exception. This link documents the HardFault Status register for the Cortex M4 and should provide some insight into the root cause of the issue.

    Can you provide the statues of the HardFault Status register when branching to the application as shown above?

    Kind regards,

    Skyler

  • Hi Skyler,

    Thanks For your response. Found What's causing the issue when branching from kernel to application PC should load with reset vector address which is second element of Vector Table. This was missing in our case found when studied the arm cortex m4 forums related to jumping from Bootloader to Application. 

    But still I want to trace out the issue just using debugger, so I tried what you suggested and found that it is a forced hard fault sharing the snippet below.


    Also, Iam Not worried about the response above as we solved the issue. Appreciated if you could explain how to trace out furthermore as I see in the document forced hard fault is set then fault handler needs to check other fault status registers to find the cause of fault this is dead end in the document what are the other fault status registers which documents talks about. 

  • Sravan,

    Glad you were able to make progress, but could you elaborate what you mean by "PC should load with reset vector address which is second element of Vector Table".

    My understanding was that at 0x00250000, you have a C initialization vector similar to the C28x side where you would call c_int00, which runs the C initialization routine and then calls main().

    Can you paste the code you have now that works?

    Thanks,

    Sira

  • Hi Sravan,

    Section 2.4.3 of the Cortex-M4 Devices Generic User Guide lists the fault status registers that should be able to help you find the cause of the HardFault.

    Kind regards,

    Skyler

  • Hi Sira,

    I mean to say kernel loads 0x00250004 into PC. At location 0x00250000 we will have the vector table. PC should load with 0x00250004 the reason because vector table first element is stack_end which is at 0x00250000. when branching happens we should not load the .text(resetisr). Instead, a pointer to resetisr.