• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 79 subscribers
  • Views 294 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.

CC3000 + FRAM demo app causes stack corruption

Reza Naima95461
Intellectual 280 points

The binary distribution of the firmware works, but I'm having an incredibly hard time modifying the firmware and making it work  - I'm using IAR's 30 day trial.  First off, trying to step though debugging fails miserably with the onboard USB interface (except for binary programming) -- I've connected a FET programmer that seems to work.

The problem occurs when a reta is called.  Rather than jumping to the address at the top of the SP, it jumps to __program_start.  The stack also seems to get mangled just after the start, the address on the top of the stack changes from 0x0000E0A0 to 0xE0A000009.

I've not experienced this before.  Any idea what my issue is?  Should I be checking out the errata?

Reza

  • 0
    Guru 227245 points

    There seems to be some confusion in the project about the used memory model.

    Older MSPs only had a CALL/RET instruction for 16 bit address space. Newer MSPs with 20 bit address space have the additional CALLA/RETA instruction. It puts 4 instead of 2 bytes on stack and takes 4 bytes as return address. The processors still suppor the 16 bit CALL/RET. However, the whoel project, including all libraries, needs to use the same code memory model, as any mixup of CALL/RETA or CALLA/RET will lead to an inconsistent stack.

    In C projects, the compiler marks in the object file which memory model was used. And the linker refusese to link object files with different model. However, for assembly files, this information is not availbale an mixup may happen, with desastrous results.

**Attention** This is a public forum