This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problem running copied code into flash

Hi everyone,

So I have a question.

I have a ARM-M4 and for what I can tell this has both ARM and Thumb assembly. Meaning sometimes it interprets a 32 bit instruction as 2 16bit ones, some of the times.

How does that work? How does it know how to go about it?

I ask this because of a project.

I have a bootloader like code. And another application code.
I configured the linker in the application code to start at 0x4000. To avoid developing the communication already, I converted the binary to a C array.

I pasted that array as a const in the bootloader code. The bootloader test code as of now just copies the array into the flash at 0x4000 and changes the vector table address to 0x4000 after that. Once all that's done, it jumps the PC to 0x4000.
The jump is done this way - I created a empty function at 0x4000. This way I just have to call it to start the app code.

The problem seems to be that the first instruction is 32bits. It seems the PC is jumping each 16bits instead of each 32. And after a few jumps it just go crazy to a really big address in the RAM.
I checked the memory and the copy was successful, exactly the same as the app code at 0x4000.

Parents
  • Hi Daith,

    Well, I always use C, so I never needed anything lower level. I got a book now on the M3 and M4.
    Did a bit of quick reading and it seems what I am experiencing is a lockup (now why, I am still searching).

    But back to instructions.

    Thanks for that info. I did not find it before. What I saw recently in the book was that the bit[0] defines if it's a 16bit or 32bit instruction.

    The dissassembly in my debugger shows the option to show mixed, ARM only and Thumb only. It's always in mixed, and when I switched to ARM only I noticed it shows some of the instructions as the same - I assume then that there are ARM instructios - or my disassembly is wrong and should never be in Mixed mode.
    When I had the same code copied (bootloader like application), the same code would appear as thumb only when the dissassembly is set to Mixed mode.

    (I am being a bit confused right? sorry, not sure how to explain it).

Reply
  • Hi Daith,

    Well, I always use C, so I never needed anything lower level. I got a book now on the M3 and M4.
    Did a bit of quick reading and it seems what I am experiencing is a lockup (now why, I am still searching).

    But back to instructions.

    Thanks for that info. I did not find it before. What I saw recently in the book was that the bit[0] defines if it's a 16bit or 32bit instruction.

    The dissassembly in my debugger shows the option to show mixed, ARM only and Thumb only. It's always in mixed, and when I switched to ARM only I noticed it shows some of the instructions as the same - I assume then that there are ARM instructios - or my disassembly is wrong and should never be in Mixed mode.
    When I had the same code copied (bootloader like application), the same code would appear as thumb only when the dissassembly is set to Mixed mode.

    (I am being a bit confused right? sorry, not sure how to explain it).

Children
  • The bit(0) in your book would be referring to the PC, not the instructions. If the bit in the PC is set then it is in Thumb mode, if 0 it is in ARM mode. The M4 and all the Cortex-M microprocessors only support Thumb mode.

    What I was telling you was a way of looking at the hex of the instructions and seeing if they were for Thumb-2 or somehow were for ARM.  If the words mostly start 0xE then it is very possibly ARM and you've set some option wrong in the code generation. The device might have ended eventually in a lockup if enough strange things happened but it is not starting in one and that is what you have got to look at so you got to trace in Thumb mode. I think though this is probably all okay if you've been doing things fine in the past.

    More likely is that thing about bit 0 in the PC is causing the problem. Sorry I should have noted that as it is sometimes a PITA. If you have put in 0x4000 rather than 0x4001 as an address to branch to it will, depending on how it is done, very likely cause an exception.