[SOLVED] RTT with dual-core STM32WB55 stops

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] RTT with dual-core STM32WB55 stops

    Hi. The STM32WB55 consists of a Cortex M4F main core and a M0+ Wireless processor using shared memory for communications between them.

    Are there any considerations/known issues using RTT on this controller?

    When using RTT with the M4F, RTT works as expected at the beginning. After starting up the M0+ co-coprocessor, RTT stops when using it with the current Ozone version on Mac.
    I've configured it to block if the buffer gets full. When I pause in Ozone, I can single-step through the _WriteBlocking as long as I want. Looking at the SEGGER_RTT_BUFFER_UP, WrOff == (RdOff - 1) as mentioned in the comments.

    To recap: RTT works on start, I receive messages up until some point after the second core has started, then the up buffer is not read although J-Link is in full control and I can single step.
    I can provide source or binaries if helpful.

    Any ideas? Thanks!
    Matthias

  • Hello Matthias,

    Thank you for your inquiry.
    How exactly is your debug setup here?
    You have one Ozone session for the CM4 core and one for the CM0. Is that correct so far?
    Where did you place the RTT control block? In the shared memory? How many control blocks are you using? For each core one?
    Are both cores writing RTT data or only one?

    If you are using an approach with one RTT control block then make sure that each core uses its own RTT up buffer. This has to be considered when writing but also reading from the target device.
    If you are using the approach where each core has its own control block keep in mind that J-Link can only read from one channel at the same time so you need to specify which control block to use.
    In Ozone this can be done using Project.AddRTTSearchRange.
    More information can be found in the Ozone user guide.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hi Nino. Thanks for the reply - I'm sorry I didn't have notifications configured and didn't see your reply in time (but fixed that just now!)

    I have a straight-forward/naive setup: start ozone, use project wizard to pick the stm32wb55xx (only two choices, with/without optional byte) and load the .elf for the CM4.

    I did not do anything about the CM0 and it has a pre-build binary from STM that implements the Wifi firmware.
    So, I assume I have a single session on the CM4 and the CM0 is left alone.

    RTT: I've used the RTT sources without changes - only change was to configure to block if full. As I did not modify the RTT control block declaration or the linker files, I conclude that the RTT control block is in the main memory (SRAM1, first 192 kB). According to the documentation, SRAM1 is accessible by CM0, but I would not expect that it looks for an RTT block and uses it by default - I also didn't see any text messages from the CM0.

    On load, Ozone auto-detects the RTT control block and enables RTT. The unexpected part is that it stops - with J-Link not reading it anymore after a few (10-50) messages. I'm starting up a Bluetooth stack, which is pretty deterministic. I would expect that it 'hangs' pretty much at the same log line otherwise.

    If I don't startup the CM0, I can log via RTT as long as like. It only stops if it gets started (it's intended as a co-processor and the CM4 can start/stop it, and there's an Inter-Processor communication controller (IPCC) as Hardware semaphore (HSEM) to coordinate them).

    As there's only a single control block and Ozone finds it on start, I didn't find other things to configure in the Ozone manual.

    Any suggestions/ideas?
    Matthias

  • Hello Matthias,

    For clarification, how are you utilizing RTT here. Just to log the CM4? Or do you want to log the CM0 as well?
    So far the issue sounds like the CM0 init overwrites the RTT buffers for some reason. Does it work if you move the RTT buffer to another non shared memory area?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hi Nino. Thanks for getting back.

    I'd like to use RTT only for the main app on the CM4. The CM0 runs the closed source radio controller software (BLE/802.15.4/Thread) from STM.
    I did not see any changes to the RTT Control Block when it stopped. I've tried to move the RTT CB to non-shared memory, but on the first look, all SRAM is accessible by both MCUs.

    When I've tried to move the RTT CB, the CM0 didn't startup at all and RTT worked correct. I'll need to figure what's caused that (I did update Ozone, but I wouldn't blame it before doing more tests).

    I'll report back when CM0 starts up again and I can continue with the RTT analysis.

    Best regards,
    Matthias