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.

SEM_postEnterKnl seems to jump to unused program memory

Other Parts Discussed in Thread: TMS320F28335

Hello!

I'm facing a problem with out code crashing. I'm using TMS320F28335 with DSP/BIOS 5.41.13.42 on a custom board and CCS 5.1.1.00031.

We have connected an SPI eeprom to the DSP along with other SPI devices. The SPI bus has its own task handling the I/O. Other code puts requests in a queue which the SPI task reads and performs the requests. The completion of a read is indicated by a semaphore.

The crashes occur when a lot of data is cleared in the eeprom (lots of SPI activity). The command to clear the eeprom is given trough a custom debugger interface which make heavy use of SYS_sprintf.

When the DSP crashes it goes to the illegal instruction trap. It seems to have to do with the semaphores. I put a breakpoint in the illegal instruction trap at took a look at the RPC register to get a idea what was the last thing that was called.

The RPC contained the address 0x3159E9, which is in the SEM_postEnterKnl routine. The instruction at 0x3159E9 is a "LCR 0x318bbe". Here comes the interesting part. That address does not contain any data (0xFFFF) which is the ITRAP1 instruction. Thus the jump to the illegal instruction trap.

Is this a bug in the DSP/BIOS or what could it be?

Relating to this problem we have situations where the watchdog doesn't seem to work. In case of a illegal trap, the ISR function should do a shutdown and then wait for a watchdog reset. The watchdog reset didn't always work. That is to say the device hang for 5-10minutes or forever and a power cycle was needed to reset it. I tried to check with the debugger what was going on, but it coudn't get contact with the 28335, or said that the execution was at 0x0.

  • Hi,

    Just looking at your screen shots, look like you are blowing one of your task stacks.

    Its looks to me like the stack of one task is jumping to another stack containing (0xBEEF).

    Could you please check to make sure your stacks (TSK and HWI) are okay.

    Judah

  • Hi!

    I found the problem. I was that in some cases, the semaphore that would indicate that a read is complete was deleted. So a semaphore that didn't exist anymore was being used. This explains well why the code crashed in the post semaphore section.

    Thanks for the help.

    Anders