Stack usage in Serial Flash Target application for OMAP-L138 LCDK

Patrick McCloskey70

Prodigy 120 points

Other Parts Discussed in Thread: OMAP-L138, TMDSLCDK138, OMAPL138

I recently began working on a project based on the OMAP-L138.

I am using an OMAP-L138 LCDK (TMDSLCDK138) to become familiar with the processor and the development environment.

I have not developed software for an ARM processor before.

I have worked with C6000 and C5000 DSPs in the past with CCS.

I am trying to learn as much as I can about the Serial Flash Host (sfh) and Serial Flash Target (sft) applications available in the OMAP-L138 LCDK starterware.

I downloaded the executable files and source code for the OMAP-L138 Flash and Boot Utils 2_40. ( http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138

I followed the instructions to rebuild the tools found here:

( http://processors.wiki.ti.com/index.php/Rebuilding_the_Flash_and_Boot_Utils_Package )

NOTE: The version of Code Sourcery G++ Lite is no longer available. I obtained a trial version of Mentor Graphics Sourcery CodeBench 2014.11-36.

I set ARM_TOOLS_PATH to the arm-none-eabi compiler there.

I was able to build the sfh and sft applications successfully and use them to load a starterware ARM core user bootloader and a DSP uart echo application into NAND Flash on my LCDK.

Next, I pointed ARM_TOOLS_PATH to the arm-none-eabi compiler included in CCSv6.1.0.

Again, I was able to build the sfh and sft applications successfully and use them to load a starterware ARM core user bootloader and a DSP uart echo application into NAND Flash on my LCDK.

I installed Microsoft Visual Studio Community 2015 (free version) so I could create a C# project with the Serial Flash Host (sfh) application code.

I created a CCSv6.1.0 project for the Serial Flash Target (sft) application. I configured the project for debugging with no optimization.

I modified my Visual Studio sfh project to embed the sft.out file from my CCSv6.1.0 project.

When I try to use the new sfh and sft applications, it hangs.

After some study, it looks to me like the code generation tools are putting the stack in the middle of code space. As the program executes, something tramples on code. I observed this using an XDS100v2 emulator attached to my LCDK.

Examining map files, it appears the code generation tools are not putting the stack where it was originally desired.

Since I do not have experience with software development for ARM processors, I do not know the correct way to place a stack section. Is it done correctly in the OMAP-L138 Flash and Boot Utils 2_40? If not, what is the correct way to place a stack section?

over 8 years ago

0 Shankari G over 8 years ago

TI__Mastermind 43955 points

Hi Patrick,

The best way is to use the "Code composer studio itself to Create the ARM project, load it into the target board and do real time debugging using the CCS plus emulator.

Patrick says said:
Since I do not have experience with software development for ARM processors, I do not know the correct way to place a stack section. Is it done correctly in the OMAP-L138 Flash and Boot Utils 2_40? If not, what is the correct way to place a stack section?

As I understand, you are trying to flash the ARM code using the Flash and boot utilis. If yes, the ARM examples can also be flashed easily using the same Flash and boot utiis. There should not be any stack related problems.

Usully, linker command file ( of the app code ) is the one which denotes the stack section.

Patrick says said:
Again, I was able to build the sfh and sft applications successfully and use them to load a starterware ARM core user bootloader and a DSP uart echo application into NAND Flash on my LCDK.

As you are successful in this step, then I do not see any problem. You mean , for sfh, you want to create a UI based developing and debugging environment using the Microsoft Visual Studio.... Is that right???

I don't think that it is officially released.So far, we can edit the sfh source code and re-build and use it, that's it.

Is your question is to debug the ARM application or the sfh application??

If it is ARM application,

The best way is to use the "Code composer studio itself to Create the ARM project, load it into the target board and do real time debugging.

If need any help in creating the ARM projects in CCS and debugging using CCS, please revert.

0 Patrick McCloskey70 over 8 years ago in reply to Shankari G

Prodigy 120 points

Hi Shankari:
Thank you for the response.

Here are a couple of my short-term goals:
1) Better understand the serial flash target (sft) application that runs on the ARM core of the OMAP-L138. This will form the basis of a software update management subsystem I need to put together.
2) Better understand the serial flash host (sfh) application that runs on a PC. I can use this as a model for test code that I might develop in the future.

I can decompose these two goals further to give you more insight into my observations in my initial post.

Goals:
1) Better understand the serial flash target (sft) application that runs on the ARM core of the OMAP-L138.
a) Establish an environment to build the sft application from source code provided by TI.
Status: DONE.
I can rebuild the sft application using either the arm-none-eabi compiler from Sourcery CodeBench 2014.11-36 or the arm-none-eabi compiler from TI CCSv6.1.0.
b) Establish a debug environment for the sft application.
Status: Work in progress.
Issue: I believe stack activity is corrupting code space in memory on the OMAP-L138 ARM core.

2) Better understand the serial flash host (sfh) application that runs on a PC.
a) Establish an environment to build the sfh application from source code provided by TI.
Status: DONE.
I can rebuild the sfh application using the C# compiler (csc.exe) provided in the .NET framework.
b) Establish a debug environment for the sfh application.
Status: Work in progress.
Issue: I believe stack activity is corrupting code space in memory on the OMAP-L138 ARM core running my debug version of the sft application.

Patrick

0 Patrick McCloskey70 over 8 years ago in reply to Shankari G

Prodigy 120 points

I am attaching a compressed 7zip archive containing my slightly modified version of the OMAP-L138 Flash and Boot Utils (based on 2_40).

I will post some additional comments in a separate post.OMAP-L138_FlashAndBootUtils_updateA.7z

Patrick

0 Patrick McCloskey70 over 8 years ago in reply to Patrick McCloskey70

Prodigy 120 points

I followed the guidance on the "Rebuilding the Flash and Boot Utils Package" wiki page.
( processors.wiki.ti.com/.../Rebuilding_the_Flash_and_Boot_Utils_Package )
I tried it with the arm-none-eabi compiler from Source CodeBench 2014.11-36 and from TI CCSv6.1.0.
When performing a top-level "make", I see that the following happens:

1) sft_OMAPL138_LCDK_NAND.out is created using the arm-none-eabi compiler and linker from TI CCSv6.1.0.
2) sft_OMAPL138_LCDK_NAND.bin is generated from the .out file using HexAIS_OMAP-L138.exe
3) sfh_OMAP-L138.exe is created using the C# compiler (csc.exe) included in the .NET framework on my PC. sfh_OMAP-L138.exe includes sft_OMAPL138_LCDK_NAND.bin as an embedded resource.

I can use sfh_OMAP-L138.exe to update the NAND Flash on my OMAP-L138 LCDK.

Now, I want to be able to single-step through the sft application in a debug environment.

I created a CCSv6.1.0 project for the sft application using the identical source code files used in OMAP-L138_FlashAndBootUtils_updateA\OMAP-L138\GNU\sft\build\makefile
This project can be found here in the compressed archive that I uploaded to this thread.
OMAP-L138_FlashAndBootUtils_updateA\OMAP-L138\CCS\sft\
I included a post-build step to generate an AIS file sft_OMAPL138_LCDK_NAND.bin from the .out file using HexAIS_OMAP-L138.exe. The AIS file is found here:
OMAP-L138_FlashAndBootUtils_updateA\OMAP-L138\CCS\sft\Debug\sft_OMAPL138_LCDK_NAND.bin

I created a Visual Studio Community 2015 (free version) C# project for the sfh application for the PC.
This project can be found here:
OMAP-L138_FlashAndBootUtils_updateA\OMAP-L138\VS\sfh_using_TI_GNU_ARM_and_make
When this project includes sft_OMAPL138_LCDK_NAND.bin from the "make" process (point 2) above), I can successfully update NAND Flash on the OMAP-L138 LCDK.

I created a second version:
OMAP-L138_FlashAndBootUtils_updateA\OMAP-L138\VS\sfh_using_TI_GNU_ARM_and_CCS_with_debugging\
This version includes the sft_OMAPL138_LCDK_NAND.bin from my CCSv6.1.0 project as an embedded resource.
OMAP-L138_FlashAndBootUtils_updateA\OMAP-L138\CCS\sft\Debug\sft_OMAPL138_LCDK_NAND.bin
When I launch this application, the process stalls while processing command:
UBL_MAGIC_FLASH 0x55424C10 /* Download via UART & Burn UBL and application image */
I examined the map file:
OMAP-L138_FlashAndBootUtils_updateA\OMAP-L138\CCS\sft\Debug\sft.map
The __stack symbol is placed between "main" and "UART_open" at 0x80004410.

.text 0x8000203c 0x2328 ./nand.o
0x8000203c NAND_open
...
0x800033d0 NAND_protectBlocks
.text 0x80004364 0xac ./sft.o
0x80004364 main
.text 0x80004410 0x0 ./start.o
0x80004410 __stack
.text 0x80004410 0xa08 ./uart.o
0x80004410 UART_open
...
0x80004858 UART_checkSequence
0x80004970 UART_recvHexData
.text 0x80004e18 0x1328 ./uartboot.o
0x80004e18 UARTBOOT_copy
.text 0x80006140 0x22c ./util.o
0x80006140 UTIL_getCurrMemPtr
...
0x80006348 UTIL_waitLoopAccurate
0x8000636c . = ALIGN (0x4)

I find the following in the linker script file:
OMAP-L138_FlashAndBootUtils_updateA\OMAP-L138\GNU\sft\ARM_sft.lds

STACK_START = 0x80008800;
STACK_SIZE = 0x00000800;

This discrepancy has me concerned.
The original developer of the sft application appears to have wanted the stack the be placed at 0x80008800 but the linker puts it at 0x8004410.

Assembly file OMAP-L138_FlashAndBootUtils_updateA\Common\arch\arm926ejs\start.asm uses __STACK_SIZE (0x800). This puts the initial top of the stack at 0x80004C10 in the vicinity of the UART_recvHexData(...) function.
I have been able to watch the program corrupt this area of memory using my XDS100v2 emulator connected to my OMAP-L138 LCDK.

I modified OMAP-L138_FlashAndBootUtils_updateA\OMAP-L138\GNU\sft\build\makefile to create a sft_OMAPL138_LCDK_NAND.map map file for the serial flash target application so I could compare the map file from the "make" process
OMAP-L138_FlashAndBootUtils_updateA\OMAP-L138\GNU\sft\build\sft_OMAPL138_LCDK_NAND.map
to the map file from my CCSv6.1.0 application
OMAP-L138_FlashAndBootUtils_updateA\OMAP-L138\CCS\sft\Debug\sft.map
I observe the following:
The __stack symbol is not placed at 0x80008800. It appears at 0x80003508.

.text 0x80001ca0 0x1354 nand.OMAPL138_LCDK_NAND.obj
0x80002014 NAND_reset
...
0x80002fe8 NAND_protectBlocks
.text 0x80002ff4 0x514 device_nand.OMAPL138_LCDK_NAND.obj
.text 0x80003508 0x0 start.OMAPL138_LCDK_NAND.obj
0x80003508 __stack
0x80003508 . = ALIGN (0x4)
*(.text:.start)
*(.text)
0x80003508 . = ALIGN (0x4)

With a stack size of 0x800, the initial top of the stack would be 0x80003D08.
It looks like it is beyond the end of the .bss section.

.bss 0x80003ac4 0x34
*(.bss)
.bss 0x80003ac4 0x4 sft.OMAPL138_LCDK_NAND.obj
...
.bss 0x80003af0 0x0 start.OMAPL138_LCDK_NAND.obj
*(COMMON)
COMMON 0x80003af0 0x8 sft.OMAPL138_LCDK_NAND.obj
0x80003af0 hUartInfo
0x80003af4 gEntryPoint
0x80003af8 . = ALIGN (0x4)
*(.bss)
*(COMMON)
0x80003af8 . = ALIGN (0x4)

I wonder if it is just working by accident.

I would be grateful if someone with more experience with ARM development using the arm-none-eabi compiler would evaluate the stack placement mechanism used in this code.
Is this the way it should be done?

0 Patrick McCloskey70 over 8 years ago in reply to Patrick McCloskey70

Prodigy 120 points

I decided to see if I would have better luck using the Mentor Graphics Sourcery CodeBench 2014.11-36 to create the sft_OMAPL138_LCDK_NAND.out application.

After a few hours, I still have not yet succeeded.
I initially specified a target configuration specifying the TI OMAP-L138 EVM.
I realize the OMAP-L138 EVM is not the same as the LCDK, but I wanted to see how far the setting would carry me.
It looks like a target configuration for a TI OMAP-L138 EVM board forces the project to use omapl138evm-ram.ld as the linker script. It ignores ARM_sft.lds.
I switched the target configuration to board: Configure Manually.
After that, the project used ARM_sft.lds as the linker script.

Now, I cannot figure out how to get CodeBench to compile the start.asm assembly file.
I turned on verbose output and it looks like CodeBench completely ignores start.asm.

The build gives me a warning at the bottom:
c:/mgc/embedded/codebench/bin/../lib/gcc/arm-none-eabi/4.9.1/../../../../arm-none-eabi/bin/ld.exe: warning: cannot find entry symbol start; defaulting to 80000000

This is looking like it is more trouble than it is worth.
Is there a reason I should continue with this exercise?

Does a Code Sourcery G++ Lite project for the sft application exist? If so, may I use it as a model as I create a Sourcery CodeBench 2014.11-36 project?

0 Shankari G over 8 years ago in reply to Patrick McCloskey70

TI__Mastermind 43955 points

Hi Patrick,

patrick says said:
This is looking like it is more trouble than it is worth.
Is there a reason I should continue with this exercise?

I would not recommend you continue this exercise and at the same time, it is not very bad though.

The reason is, spending lot of time for developing "tools" ( sfh / sft ) may not be worth.

It is just fair enough as long as we could edit/ modify the source of the tools such as sft/sfh and rebuild it successfully. As you already mentioned that you are able to re-build it properly and flash the images into the memory, that's it. Once done correctly, it will stand by once for all. May be heere and there, modifications needed as per the board changes and requirements. But one would not be much interested in debugging the tools...Instead few print messages inserted inside the source would do the needful.

And also, to be honest, this is the first time in this community, I came across that one is looking for project specific files for the flashing tools to create development environment.

You can take up a call and decide upon... : ) .

All the best!.

0 Patrick McCloskey70 over 8 years ago in reply to Shankari G

Prodigy 120 points

I think it boils down to this:

It looks like the stack section is intended to start at STACK_START = 0x80008800 in linker script ARM_sft.lds
However, in the generated map file sft_OMAPL138_LCDK_NAND.map, a ".stack" section was created without a specific address and symbol __stack appears at address 0x80003508.
How should I modify the linker script file ARM_sft.lds and/or assembly file start.asm to place the stack section and the __stack symbol at 0x80008800?

I will attach four relevant files here.

makefile - updated to output a map file for the sft application

start.asm - assembly file with start( ) function

ARM_sft.lds - linker script

sft_OMAPL138_LCDK_NAND.map - map file generated by the make process