SYSBIOS 6.35.00.20 works, SYSBIOS 6.35.01.29 causes XDC runtime exception

Hi Dean,

We did not make any changes in 6.35.01.29 (relative to 6.35.00) that would affect C674. I would suggest debugging this problem further and determine what is causing the exception.

Best,

Ashish

Well that will be just about impossible.  The exception is happening in a 3rd party module, and we only have the binary library.  We've used this 3rd party module for 100's of builds using every version of SYSBIOS, right up to 6.35.01.29 where it crashes.

Is the "C runtime libraries now reentrant" not for the C674x?

Not that I want to muddy the waters too much about this 3rd party library, but we've been unable to use in projects that use the C6000 7.4.xx compile tools.  We are currently building everything with the C6000 7.3.xxxx compile tools (7.3.12 to be exact).  I don't think that has anything to do with our SYSBIOS problem, just wanted to mention it.

Thanks, Dean

Hi Dean,

The "C runtime libraries are now reentrant" statement only applies to GNU targets. C674x only has a TI target and uses the TI C runtime library which is re-entrant (SYS/BIOS provides the necessary locks to ensure the library's reentrancy).

Do you get the same exception every time (Supervisor read violation exception at same address) ? I am trying to understand if the exception is random or deterministic. Also, can you see which instruction is causing the exception using the disassembly window ?

Best,

Ashish

Ashish,

The exception happens at the same spot in code every time.  Attached is a snapshot of the assembly code that generated the exception.  Remember, this is a binary library, so I have no source code to reference.

Please note that the address below that generates the exception is different than my original post because we continuously make changes to the project.  However, this instruction in this 3rd party library always causes the problem.  I built this project with SYSBIOS 6.35.00.20 moments before, and everything ran fine.

Thanks, Dean

Hello, anybody still working on this problem?  We will be stuck on SYSBIOS 6.35.00.20 until this is resolved.  We are three SYSBIOS versions behind, and the following bugs have been fixed since then.

SDOCM00099468    Clock_getTimeout() returns incorrect values for active objects if the timeout is greater than 1/2 of the maximum timeout

SDOCM00099411    Task_delete of a task in the READY state can result in an orphaned clock object and eventual application crash

SDOCM00100800    ti.bios.support package is not exporting libraries for SYS/BIOS 6.35.00/01.  6.34.0x is OK.

SDOCM00100665    cannot set event object handles for Mailbox or Semaphore with xgconf

SDOCM00090117    BIOS 6: Add task stack back trace ROV view for each task.

- Dean

Hi Dean,

Just a suggestion.
If you clear all IRAM and External RAM memory with zero before running executable, do you see the exception ?
If changing the initial value of memories improves the situation, It means something software should be missing
the memory initialization. You can focus on the issue by narrowing down the clearing area.

You see the supervisor read violation exception at 0xc6dc2b78. I'm not very sure about this exception exactly,
but I see the read (LDH operation) at 0xc6dc2b60,  0xc6dc2b64, and 0xc6dc2b68. And LDH operation has 4 delay slots until it accomplishes the operation, so what address is actually used for loading on LDH (especially 0xc6dc2b68) may be a key for further debugging.

Hope this helps.
Kawada 

Hi Dean,

From the disassembly you shared earlier, it looks like the exception occured because of the read operation at 0xc6dc2b90. It would be interesting to see what address was being read and where does it fall in the memory map. B5 equals B5 + A10, where B5 is 0x18C and A10 can be determined from the exception log. Can you compute B5 and check what is there at that address ?

I feel there might be a problem with this 3rd party library and you were getting lucky with SYS/BIOS 6.35.00.xx. Another thing to try would be to try and build with the newer 6.35.02.xx/6.35.03.xx releases and see if you get the same exception ?

Best,

Ashish

For both version of BIOS, B5 is pointed to an address where the next (4) bytes are 0x00.  A snapshot is provided below.

For some reason SYSBIOS 6.35.00.20 doesn't mind this pointer to 0x00000000, but newer SYSBIOS's crash.  We did notice something else about SYSBIOS versions greater than 6.35.00.20.  We had "bad" code in our project for years that sometimes would try to do a strlen() with a NULL pointer passed as the variable.  When we first upgraded to a SYSBIOS version greater than 6.35.00.20, our project crashed on all the calls where the pointer to strlen() could be NULL.  We had to fix all of those cases first to get the code working.  Then we discovered this exception in the LEC that is crashing our code.  It seems the two are linked somehow.

By the way, we tried multiple versions of SYSBIOS beyond 6.35.00.20, and they all crash.

- Dean

Ashish,

Thanks for your help, that was the problem.  I deleted the Exception Module from our app.cfg, rebuilt with SYSBIOS 6.35.01.29, and now all is well.

I will have to work with our 3rd party vendor to fix their library.

Thanks, Dean