TMS320F28388D: Why is c_int0() not called in flash kernel examples

Huey, correct, the Flash kernel does not invoke the Compiler's C runtime initialization routine. That is invoked when the Flash kernel hands off control the application - the C runtime initialization routine is invoked prior to calling the Application's main()

Thanks,

Sira

I understand the application needs to run c_int0.   But doesn't the flash kernel itself also need to run c_int0? It's written in C.

Huey, yes, strictly speaking, this is the right way to go about it. But it also works without.

Thanks,

Sira

Can you please be more specific on how it works without it?

What sets up the C runtime environment before the flash kernel is run?

Or is it that you don't need to set up the C runtime environment when running C code.  The later does not seem right.

Huey,

Let me check on this and get back to you in a day or two.

Thanks,

Sira

Huey, 

The C init routine is normally called when running C code. In the case of the kernels, there is a custom ExitBoot routine that needs to be run after the kernel has finished executing which passes the application entry point to the device, and this routine would not be run if the C init function is called, so it is is commented out. 

Thanks,

Anu

Hi Anu, thanks for getting back to me.

That would explain why the kernels do not call the c init routine so that it can hand off to the final application code. Thanks.

But the part I still need help understanding is the kernel code itself.  The kernel code is running C code. 

If it does not run c_int00, then what code performs c_int00 steps 1-4 to set up the C environment for the kernel code to run C code?

What sets up the status, configuration regs, stack, .cinit for the flash kernel code?

Regards

Huey, 

I will check on what is happening if #1 is not being performed, but for the kernels, the default stack pointer value of 0x400 is used so there is not an issue with not performing #2. #3 is not needed since the --rom_model option is not used, and for #4, the global variables are initialized during kernel operations so there are no issues caused by it not being performed. 

Thanks

Anu

Thank you for taking the time to dive into my questions.  You've helped me understand this a bit more.

In regards to your response, can you please continue to support the line of questioning per c_int0 task item. 

It would really help to port f2008x kernel code to f28388 and add our own features.  

Re #1: eagerly awaiting your response.

Re #3: The f28002x_sci_flash_kernel example is using --rom-model.  But looking at the map file, it looks like the global data symbols don't need to be initialized as they are done so in the code.  Is this correct?

RE #4: This task refers to calling global constructors (.init_array for EABI).  I assume that this code is not using any global constructors hence there is no need to manage .init_array.

================ Limitations to C code when not calling c_int00===================

Sounds like c_int00 is not called in the flash kernel code so that it can pass execution to the final application, but because it isn't called, there are limitations to what the flash kernel C code can do:

#1 TBD waiting response for TI

#2 do not change the stack pointer in .cmd file from default. (F2008x is 0x400).

#3 do not use global variable initialization (.cinit).  Must initialize global variable in code (.text).

#4 do not use global constructors (.init_array)

Regards

Huey Duong said:

Re #3: The f28002x_sci_flash_kernel example is using --rom-model.  But looking at the map file, it looks like the global data symbols don't need to be initialized as they are done so in the code.  Is this correct?

Yes, they are initialized in code. 

Huey Duong said:

#1 TBD waiting response for TI

I am still working on this, but it looks like action 1 is used for selecting the C28x object mode which is also done in the codestartbranch file, and setting any FPU settings which are not relevant for the kernels. 

Thanks

Anu