• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 861 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.

SYS BIOS: malbox allocated buffer different between CCS debug mode and after the board is resetted

Nolwenn Jarossay
Prodigy 90 points

Other Parts Discussed in Thread: SYSBIOS

Dear All,

I am facing a mailbox memory corruption issue using SYS BIOS. That bug appears when the board has been resetted and runs by its own, and not using the CCS "Debug session".

When I have more than one message pending in my mailbox, the pend function reads the last message ( not the first ), and then try to read the next one but data is corrupted.

I looked in the malbox's AllocBuf in CCS debug session:

There is reserved space for 10 messages : the size is 6 words, plus 4 words for next and prev pointers.

I implemented a function to be able to see this memory space, using a GUI, To retrieve the Alloc buf pointer, I used that code:

ti_sysbios_knl_Mailbox_Struct * mbx_struct;

mbx_struct = ti_sysbios_knl_Mailbox_struct( my_mailbox );

ptr = (UINT16 *) mbx_struct->__f5;

I checked that this code works in CCS debug mode, and returns the current content of the buffer.

After I reset the board, the function displays the buffer:

As you can see, most of the buffer is set with zeroes. I read it just after reset, nothing is posted inside the mailbox.

My question is: can you confirm that my mailbox alloc buffer is corrupted, and it is why I can only have only one message in it? Or I will read some random values?

Or is it normal, and the alloc buffer is initialized in a different way by SYS BIOS, between the CCS debug mode and after reset?

Thanks a lot,

Nolwenn

  • 0
    TI__Mastermind 45025 points

    Hi Nolwenn,

    Which hardware platform are you using?

    Nolwenn Jarossay said:
    I am facing a mailbox memory corruption issue using SYS BIOS. That bug appears when the board has been resetted and runs by its own, and not using the CCS "Debug session".

    Can you please clarify?  What do you mean by a "resetted and run on its own?"  Does that mean a power cycle?  Or are you doing a CPU reset within CCS' debug session?

    Sounds like you have an application that works fine when you open a debug session, connect to the processor, then load/run the app.  Is that correct?

    But then you are trying reset the board,  and expecting the application to run?

    Steve

  • 0 in reply to Steven Connell
    Prodigy 90 points

    Hi Steve,

    Sorry I forgot to give more details.

    The platform is a Concerto F28M35H52C1; The loaded code is for the c28 component.

    The bug appears when I am doing a power cycle. And yes the application works fine when I open a debug session, connect to the processor and run the application.

    Then I am performing a power cycle, and the application seems to work like in Debug mode... except for the mailboxes.

    Thank you,

    Nolwenn

  • 0 in reply to Nolwenn Jarossay
    TI__Mastermind 45025 points

    When you connect in your CCS debug session, is there a GEL file set for your Concerto target configuration?

    Typically when loading a program, CCS runs the GEL script first, which could be doing some initializations that you need.  If you just power cycle the board, the GEL scripts are not being run prior to executing.

    Steve

  • 0 in reply to Steven Connell
    Prodigy 90 points

    Hi Steve,

    Yes, there is a GEL file set for my concerto target configuration; and it is the default one for Concerto.

    I performed a "disconnect/connect" in CCS debug mode, and noticed that the memory was initialized to zero. And then I performed a "restart", and noticed that some parts ( Mailboxes buffers included) were initialized with values...

    So it looks like thoe memory difference are related to GEL file.

    But is there some functions that I can use, and initilialize the memory like a GEL file would do, but after a power cycle?

    Thanks a lot,

    Nolwenn

  • 0 in reply to Nolwenn Jarossay
    TI__Mastermind 45025 points

    Hi Nolwenn,

    I'll need to ask someone for more details, but I believe what you need to do is to make the GEL functionality part of your boot up sequence.  This can be done using various 'startupFxns'.

    It may help you to refer to the start up sequence that's described in the BIOS module in your SYS/BIOS API guide:

    The RTSC runtime startup sequence is as follows:
    1. Immediately after CPU reset, perform target-specific CPU initialization (beginning at c_int00).
    2. Prior to cinit(), run the single user-supplied "reset function" (see Startup.resetFxn).
    3. Run cinit() to initialize C runtime environment.
    4. Run the user-supplied "first functions" (see Startup.firstFxns).
    5. Run all the module initialization functions.
    6. Run pinit().
    7. Run the user-supplied "last functions" (see Startup.lastFxns).
    8. Run main().
    The SYS/BIOS startup sequence begins at the end of main() when BIOS_start() is called:
    1. Run the user-supplied "startup functions" (see BIOS.startupFxns).
    2. Enable Hardware Interrupts.
    3. Enable Software Interrupts. If the system supports Software Interrupts (Swis) (see BIOS.swiEnabled), then the SYS/BIOS startup sequence enables Swis at this point.
    4. Timer Startup. If the system supports Timers, then at this point all statically configured timers are initialized per their user-configuration. If a timer was configured to start "automatically", it is started here.
    5. Task Startup. If the system supports Tasks (see BIOS.taskEnabled), then task scheduling begins here. If there are no statically or dynamically created Tasks in the system, then execution proceeds directly to the Idle loop.

    Steve

  • 0 in reply to Steven Connell
    TI__Mastermind 45025 points

    Hi Nolwenn,

    I asked around and I'm not sure that my previous answer was correct.  I think you need to use the C28 Boot module.  You can find the info about it in these threads:

    The following wiki page also has some info on the BIOS Boot module for C28:

    http://processors.wiki.ti.com/index.php/SYS/BIOS_for_the_28x

    Hope this helps...

    Steve

  • 0 in reply to Steven Connell
    Prodigy 90 points

    Hi Steve,

    Thank you for your links, they are very useful!

    I have a good new: We have been able to reproduce the bug when still in CCS debug mode ( using another board for the power cycle).

    I added a reset function, to be able to stop the device and see the memory after a reset.

    I noticed that, when there was a breakpoint, the memory was initialized correctly; and when there was no breakpoint... the memory was corrupted. So I wondered if the fact of stopping temporary the DSP woult help it to initialize correctly.

    Now, during that reset, the code is now performing a loop, basically to delay the DSP memory initialization. And it seems that our mailboxes are no more corrupted....

    I don't know why delaying the DSP initialization is "solving" that problem. Perhaps there is like a desynchronisation between the cortex and the c28?

    Thanks a lot,

    Nolwenn