• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 889 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1350: CC13x0 ROM source

raryanpur
Prodigy 50 points
Part Number: CC1350
Other Parts Discussed in Thread: CC1310

I'm debugging an application where my debugger is showing my application stuck executing the same sequence of 10 sequential memory addresses as I single step through the code. The memory addresses are in the 0x1000 abcd domain, so the application is stuck in ROM (0x1000 is ROM, according to rom.c in the cc13x0 driverlib), and my hunch is that it's stuck in some sort of loop, possibly waiting on some state or data that never comes across. My problem is that I can't debug further because I don't have the binary and symbols for the cc13x0 ROM. I've searched the TI website and Google and while these items are available publicly for the MSP432, I can't find them for the cc13x0. Are the binary and symbols for the CC13x0 ROM available publicly, or can TI provide them?

Another possible debugging approach is to disable the ROM driverlib, so that I can single step through the NOROM version of whatever function is being called, but my application pretty much consumes all of the onboard Flash of the device, so there's not enough space to  just link in the NOROM versions of the driverlib into my binary.

Note I've checked the value of the fault register (0xE000ED28), and the value is zero, so I know the device hasn't faulted.

  • 0
    TI__Guru**** 317180 points
    Does e2e.ti.com/.../2054899 answer some of your questions?
  • 0
    Expert 2050 points

    The 0x1000 region has zero information available - I've looked and asked for months but only managed to glean that it's part of the internal ROM bootloader.

    The TI staff commonly tout two fixes, neither of which work:

    They say put kernel in flash. Even if you put kernel in flash, it will still call functions in this region, so "put kernel in flash" does not solve this.

    They say "load the rtos_rom golden image". Even if you load this image, there are no symbols available for the 0x1000 region, so "load the rtos_rom golden image" does not solve this. The image only covers the 0x1001 range but not 0x1000, and furthermore has a bunch of symbols for other addresses in flash and in ram which can make debugging very confusing if you are using kernel in flash.

    The most frustrating part about this issue is that the PC is in this region 99% of the time when I hit pause so I can't imagine that the TI staff have any trouble reproducing it, yet this issue makes TI's debugging toolchain look very incapable straight off the bat since CCS can't backtrace past any address it doesn't have debug symbols for.

    Apparently the TI compiler can't emit stack frame pointers, or CCS doesn't understand them, or possibly both. I've searched long and hard for an option to enable this feature (which is common in other toolchains) to no avail.

    For your reference, I've managed to work out a few addresses:

    0x10000486 is the power mode standby function - kernel jumps here when it wants to be in standby until something wakes it up.

    0x10003A12 is the reset vector - your CC1310 will deadlock here until you enter and exit debugging (or toggle reset or powercycle) if your code spontaneously reboots, due to the halt-on-boot flag being set after programming even if you don't use CCS to program it.

    0x10002212 (or something like it, had a bunch of 2s) may have been power mode idle or WFI (as opposed to standby) although I haven't seen this one for a while since I don't run stuff from CCS anymore and my application demands proper standby.

    Hope that helps

  • 0 in reply to Michael Moon
    TI__Guru**** 317180 points
    I have made a ticket to improve the documentation on this.
  • 0 in reply to Michael Moon
    Prodigy 50 points

    Michael, thanks so much for your highly informative and detailed response. I definitely feel the same frustrations you outlined. Perhaps one bright side for me has been that I've learned a ton about the debugging process and the capabilities of various toolchains. Of course it's a bit hard to lean on that positive spin when I'm in what seems like the zillionth hour of debugging with little/non-existent documentation. Anyway, thanks again for sharing your experiences and what you've been able to decipher about those few addresses.

    TER, thanks for the original link to the golden image. Unfortunately I'm not working with TI-RTOS, so I don't think that loading the ROM symbols from the golden image would help in my case. Regardless, thanks for putting in a ticket to improve the documentation on this, and let me know if there's anything we can do to escalate this so that it gets some eyes as soon as possible.