Compiler/TMS570LC4357: label in BL instruction

Hello,

Is the "asdf" function an assembly routine? Can you check this "asdf" function to see if it manipulates the contents of the R14 register? Usually functions push the link register (R14) onto the stack and then pop this value so that the execution can continue at the line of code after the function call to asdf. You can single-step the asdf function to see the mechanism used to return back to the main() routine.

Regards,
Sunil

No. It was only used to check if debugger step-into functionality works correctly.

Function body:
// todo
void asdf()
{
volatile int i = 5;
}

Are you able to get to the vTaskStartScheduler routine if you single-step through the code? Is the stack setup correctly? Do you see the link register (LR) getting pushed and popped from the stack as part of the entry and exit from the asdf function?

> Are you able to get to the vTaskStartScheduler routine if you single-step through the code?

No. This is the problem I posted.  ("I expected that after executing step into I would end in function vTaskStartScheduler at address 0xFEC but following happens"). To be more precise, I am using Assembly step into.

> Is the stack setup correctly?

Code was generated by HALCoGen so I suppose it is. (It is visible in .map file, SP register points inside range as defined inside .map file, Othervise I don know what to check).

> Do you see the link register (LR) getting pushed and popped from the stack ...

No. And I think it should not be pushed to stack. LR contains return address and it would be in vain to save it on stack if function does not make any calls.

I have additional information
- Problem occurs even without using library. I have moved all source code into project
- Problem goes away if I rename function vTaskStartScheduler to vTaskStartScheduler2. (Linker rearanges function addresses after renamining)

Subqeustion: Can I find value of assembler labels ("bl vTaskStartScheduler" - I want to check value of 'vTaskStartScheduler')

Lukas,

Addresses for all named functions are included in the .map file that is generated by the linker.

Regards,
Sunil

Address is correct: 00000fec  vTaskStartScheduler. (From MAP file)

Are there any conditions when CPU does not execute BL instruction? 

I have prepared example project for development kit TMDX570LC43HDK.

In the project instruction "bl         vTaskStartScheduler" generated from vTaskStartScheduler() call in main function does not have any effect.

There are two lines labeled with // ATTENTION comment in the source file 'HL_sys_vim.c'. :

                       | (uint32)((uint32)((HW_CNFG_AttrsObj.isrs[9].enable) ? 1 : 0) << 8U) // ATTENTION Comment this line to make jump to 'vTaskStartScheduler'

//                        | (uint32)((uint32)0U << 8U) ATTENTION Uncomment this line to make jump to 'vTaskStartScheduler'

If you comment first line and uncomment second line call to vTaskStartScheduler() stars working.

6232.test_move2d.zip

Hi Lukas,

FreeRTOS uses some RTI interrupts for its kernel. These interrupts are managed internally by FreeRTOS and must not be enabled or disabled outside of the FreeRTOS.

See this related post: e2e.ti.com/.../368633

Regards,
Sunil

I don't see how the thread relates to my problem that instruction bl does not work in some instance.

I noticed that vTaskStartScheduler is not wrapped by MPU_vTaskStartScheduler as are other function in os_tasks.c. Then I changed command file to place all code after first 32KB (all wrapper functions are placed in this region). This helped and it seems that system works.

This creates multiple following questins:

• Even first 32KB have exec permission in HALCoGen. Does it mean something else?
• Should I raise access rights before calling vTaskStartScheduler() in main function?
• Why did it have such an erratic behavior for event slight source code changes? I would expect that calling vTaskStartScheduler() would not be influenced by slight placement shift in flash memory.