March 16, 2018 at 18:56 #23138
I am trying to get the uC/OS-II code for the TI DK-TM4C129X board to work with Code Composer Studio. I am having all sorts of issues with compiler-specific include files not being present, not to mention errors when trying to assemble .asm and .s files. I noticed in the blog (see https://www.micrium.com/ucos-iii-v3-04-05/) that there is a mention of a port of uC/OS-III for CCS, but I could not find it anywhere. I thought it might help me figure out what I need to do to get stuff working.
Any idea where that CCS port might be? Or is there an application note somewhere regarding porting to CCS? I am surprised that Micrium does not seem to support that tool.
DaveMarch 17, 2018 at 16:34 #23141
The best way is to start a new project based on the MCU and copy all Micrium files into the project directory. You can use existing BSP files for a similar MCU and modify them for your MCU. It may take some time, but will be worth the effort. Can you provide details on the compiler errors?
FarukhMarch 19, 2018 at 16:02 #23154
The problem is that I am trying to build a project in Code Composer Studio, and Micrium does not have a project for the Tiva CPU I am using with a CCS port. I found a CCS project for the TI MSP432 family, which is also an ARM chip. I tried using files from that project, and was finally able to get things to build. But when I try to run the code it is branching to address 0x00000000 for some reason (deep in the RTOS assembly code) and craps out.
DaveMarch 19, 2018 at 16:48 #23155
I stepped through the assembly code, and I found where things are going wrong. In the function OSStartHighRdy in os_cpu_a.asm, the very last instruction is “BX R1”. The contents of R1 at that time is 0. From what I can tell, R1 is supposed to have been loaded with the address of the start task, but for some reason that is not happening.
Does anyone have any idea what might be going wrong?
Update: If I break at the BX instruction and manually load the address of the start task into R1, the start task begins to execute, although it behaves strangely. If I set a breakpoint where the LED is toggled, the LED turns on and off just fine. But if I just free run the LED always stays green. Very bizarre.
March 20, 2018 at 12:37 #23166
- This reply was modified 1 year, 11 months ago by David Hohl.
I will assume the following:
* You created a TM4C129X bare-metal project in CCS, which runs fine.
* You added TM4C129X BSP, uC/CPU, uC/LIB and uC/OS-II to your workspace
* you added the uCOS-II/Ports/ARM-Cortex-M/ARMv7-m/CCS port files from the Micrium MSP432 project.
* You modified the startup file from you bare-metal project to match something similar as the IAR or Keil startup files provided with the Micrium TM4C129X project.
The issue you are describing is normally due to a workspace setup, startup configuration or flash loader. if you could provide your workspace with full source code and the version CCS you are using, I could take a look at it and see where the problem is.
FernandoMarch 20, 2018 at 13:50 #23168
Your assumptions are mostly accurate. I took the tm4c129nczad_startup_ccs.c file from an existing working project and merged the Micrium files in. I do not recall modifying that startup file to match the IAR files, though, so perhaps I need to take a look at that.
I am using CCS 8.0.0.00016. How do I go about uploading a zipped project file?
DaveMarch 20, 2018 at 15:17 #23169
I double-checked, and the CCS startup file I use seems to have all the same stuff that the IAR and Keil versions have.
DaveMarch 20, 2018 at 17:44 #23171
If you could create a dropbox folder and share the link with me. I should be able to download it.
FernandoMarch 20, 2018 at 19:33 #23172
Here is a link to the file:
Thanks for your help!
DaveMarch 21, 2018 at 14:33 #23178
As Fernando indicated, those are the steps that are required. I did the same procedure in generating a STM32F4 Discovery board project using Atollic TrueSTUDIO.
FarukhMarch 21, 2018 at 15:49 #23179
I took a closer look at my cstartup file, and found that I have not initialized the IVT with the PendSV and SysTick handlers. Not sure if that would cause the problem with not branching to the startup task, but it definitely explains why the LED doesn’t blink after I manually force invocation of the startup task. I will fix the cstartup file and see what happens.March 21, 2018 at 16:22 #23181
Adding the PendSV and SysTick handlers fixed the LED blink problem.
I still have the issue with the R1 register containing 0x00000000 when the “BX R1” command is reached, though. I noticed, however, that if I do a “Restart” in the CCS debugger R1 does contain the starting address of the startup task. This seems to indicate that the problem is not in the Micrium code, but rather a debugger related issue. If, after loading the code, I disconnect the JTAG and cycle power on the board, the code seems to run okay.
Unless someone has an insight into what may be going wrong with the debugger the first time executing the code, I think my issues are resolved. Thank you, Fernando and Farukh, for taking the time to respond to my posts.
DaveMarch 21, 2018 at 17:16 #23182
Looks like I spoke too soon! The Restart trick worked for a while, but now (without changing anything) R1 always has 0x00000000 when I hit the BX instruction. And even if I enter the proper address in R1 and launch the startup task, the LED does not blink. If I set a breakpoint where the LED is toggled, though, things work fine. And they work fine if I run with the JTAG disconnected.
Update: It turns out I need to do a CPU reset — not just a restart — to get things to work.
March 21, 2018 at 17:30 #23183
- This reply was modified 1 year, 11 months ago by David Hohl.
I tracked down the issue to line 238 “MSR CONTROL, R0” in os_cpu_a.asm. This line of code is not modifying bit1 of the CONTROL register, which is what the port needs to use PSP as the current stack Pointer. This is the reason why the CPU registers are not being loaded with the correct Task Stack values to context switch. If I manually modify this bit then the registers are loaded with the proper values. Therefore, this might be an issue more with TI compiler or Segger Jlink emulator that TI provides. The XDS-ICDI debugger on my board is not working so I cannot test using the built-in debugger.
Could you try using the XDS-ICDI debugger and see if bit1 of the CONTROL register is being written? if bit1 is not being written, then this will be a question for TI Forum.
FernandoMarch 21, 2018 at 18:15 #23185
Very interesting, Fernando! Resetting the CPU might fix something that is causing that bit not to be set. I will give it a try with the IDCI and let you know.
You must be logged in to reply to this topic.