David Hohl

David Hohl

Forum Replies Created

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • in reply to: Code Composer Studio #24139

    David Hohl
    Participant

    I am still waiting to hear from Segger on this. They apparently have a large backlog of issues, and could not tell me when they will be able to look into this one.

    Regards,

    Dave

    in reply to: how to make CCS library thread-safe with uC/OS-II? #23499

    David Hohl
    Participant

    I learned from TI tech support that while they do not support a thread-safe run-time library, the TI ARM compiler provides a mechanism for registering custom lock and unlock functions that are used in the RTL to identify critical sections. See section 7.3 (Handling Reentrancy) of the TI ARM Compiler User Manual for details.

    Regards,

    Dave

    in reply to: Code Composer Studio #23451

    David Hohl
    Participant

    Sorry for the delay in posting. I thought I had posted a response a few weeks ago, but I guess I was not logged in, and I missed the message indicating that.

    I tried using the IDCI debugger, and it worked fine. I posted on the TI tech support forum, and they were able to reproduce the issue. They believe it is a Segger J-Link problem, and contacted Segger about it. Segger says they will look into it next week. I will post again when I hear back from them.

    Regards,

    Dave

    in reply to: Code Composer Studio #23195

    David Hohl
    Participant

    Hmmm, I thought I had posted my findings last night, but it looks like it did not go through, so here it is again:

    I tried using the ICDI interface, and it works fine. If I just GO after downloading, the program runs and the LED blinks. I also single-stepped through the instructions in question and verified that the CONTROL and R1 registers are indeed getting set properly.

    I have started a thread on the TI E2E Code Composer forum with the details of what we have found. Hopefully they will be able to sort things out. Once I get a resolution from them I will post here with the results.

    Regards,

    Dave

    in reply to: Code Composer Studio #23186

    David Hohl
    Participant

    OK, I tried running it with the ICDI, and it works fine. Bit 1 of CONTROL does get set by the “MSR CONTROL, R0” instruction, and the code runs fine.

    I tried again using the J-Link, and sure enough, the bit does not get set. If I manually set it, the startup task gets launched. However, if I run from there, the LED does not blink, even though if I set breakpoints at the LED toggling the LED does turn on and off. This behavior also fixes itself if I do a CPU reset.

    So it would appear that there are some serious issues with the CCS J-Link debugger. I will post on the TI web site to see if they can figure out what is going wrong.

    Thanks again for all your help!

    Regards,

    Dave

    in reply to: Code Composer Studio #23185

    David Hohl
    Participant

    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.

    Regards,

    Dave

    in reply to: Code Composer Studio #23182

    David Hohl
    Participant

    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.

    • This reply was modified 2 years ago by  David Hohl.
    in reply to: Code Composer Studio #23181

    David Hohl
    Participant

    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.

    Regards,

    Dave

    in reply to: Code Composer Studio #23179

    David Hohl
    Participant

    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.

    in reply to: Code Composer Studio #23172

    David Hohl
    Participant

    Hi, Fernando,

    Here is a link to the file:

    https://www.dropbox.com/s/hjqew6icu7tk2e4/VIO-CPU-Port.zip?dl=0

    Thanks for your help!

    Regards,

    Dave

    in reply to: Code Composer Studio #23169

    David Hohl
    Participant

    I double-checked, and the CCS startup file I use seems to have all the same stuff that the IAR and Keil versions have.

    Regards,

    Dave

    in reply to: Code Composer Studio #23168

    David Hohl
    Participant

    Hi, Fernando,

    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?

    Thanks,

    Dave

    in reply to: Code Composer Studio #23155

    David Hohl
    Participant

    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?

    Thanks,

    Dave

    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.

    • This reply was modified 2 years ago by  David Hohl.
    in reply to: Code Composer Studio #23154

    David Hohl
    Participant

    Hi, Farukh,

    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.

    Regards,

    Dave

Viewing 14 posts - 1 through 14 (of 14 total)

View the complete site map

x
Loading...