• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 79 subscribers
  • Views 1601 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/SIMPLELINK-MSP432-SDK: Instrumented driver library not included & fails to init

Campbell Young
Intellectual 310 points
Part Number: SIMPLELINK-MSP432-SDK
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hi,

I've started work on a new device that uses an MSP432 and simplelink_msp432_sdk_1_40_01_00. I prefer to develop with instrumentation enabled so that asserts are validated and logs are produced. However, 1.40.01.00 of the SDK doesn't ship with a pre-built instrumentation library. The libraries included in simplelink_msp432_sdk_1_40_01_00\source\ti\drivers\lib are: drivers_msp432p401x, drivers_msp432p4xx and drivers_msp432p4x1xi, with aem4f/am4fg/arm4f variants for each. I also can't find an instrumented dpl (kernel/tirtos/packages/ti/dpl) library, so all DebugP_logx functinos produce no output.

After googling how to use xdc properly, I managed to build the instrumented version of drivers myself. However, it failed to boot because the assertion at the start of GPIO_setConfig (line 414 in GPIOMSP432.c) fails during GPIO_init. The assert is below:

DebugP_assert(initCalled && index < GPIOMSP432_config.numberOfPinConfigs);

This fails because GPIO_init lines 324 - 334 tries to configure the pins before initCalled is set. Setting initCalled before the for loop fixes the issue.

However, this doesn't give me a lot of confidence in the quality of the SDK, so I have a few questions:

  1. Why was including the drivers via RTSC deprecated in favour of manually linking? This makes getting instrumentation quite a bit more difficult / tedious.
  2. Is the instrumented library well supported / tested? It seems difficult to get started which makes me feel it's not well used.
  3. If I want DebugP_xx to produce output, do I have to build dpl myself? I don't see any preprocessor magic that would cause logs not to work, but if I do DebugP_log0("test"), I get no output, whereas Log_print0(Diags_USER1, "test") (which is all DebugP_log0 does internally), then I see it in the logs. It's worth noting that I have logs enabled in my config, and I see normal sysbios entries in my log.

I just want to understand things a bit better before we decide to commit ourselves here.

Cheers

  • 0
    TI__Guru* 96960 points
    Hi Campbell,

    We made the decision to not ship the instrumented driver libraries for a few reasons: reduce installer size, the amount of flash on some of the devices is small (e.g. CC13xx and CC26xx) and no one was using the instrumented driver libraries, etc. We dropped the RTSC configuration for the driver mostly to reduce the ramp-up on writing new drivers.

    Unfortunately, since we don't ship the instrumented libraries anymore, they might be getting stale. That's why we don't actively talk about them in the SDK. We are looking at bringing them back in the product, but I don't have a time-frame. I'll add this thread link into the Jira ticket to show that customers are asking for it though. So the answer to your #2 question would have to be "no", the instrumented library is not well supported or tested.

    Which example gave you the assert? I'd like to run it and see if I can reproduce it.

    Regarding number 3, are the DebugP_logN functions showing up in your mapfile?

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 310 points

    Hi Todd,

    Thanks for clearing that up, I think I'll just switch into my instrumented builds if/when I have issues with drivers. I didn't run any particular example to get GPIO_init to fail, but as far as I can tell, any call to it that configures pins with instrumentation will fail.

    I also got DebugP_xx to print by building DPL myself, I guess the pre-built one has printing disabled. I've made my sdk install a bit of a mess with these custom builds, so it's not super easy for me to check if it's in my map with the shipped library. I would assume so, however, because it linked correctly when I called DebugP_log0 directly, it just didn't produce any output. 

    I think I'll revert back to the shipped libraries now though because that is what's tested. This was a useful little exercise though, now I understand the xdc build system a lot better.

**Attention** This is a public forum