• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 80 subscribers
  • Views 1369 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.

MSP430F5438A: Switching MCU execution from Large to Small Instruction Set

Diogo Guerra2
Prodigy 40 points
Part Number: MSP430F5438A


Hello,

We developed a bootloader that runs on normal FLASH and handles a client application (the guest code) also written in normal FLASH.

But we have a problem. Although the bootloader can run Guest Code if this code is compiled in extended format (so that the processor can use 20bit addressing and thus all the available ROM) loading guest code compiled with 'normal' flags (without address extentions) when our bootloader jumps to execute code it  stops running...

My view of the problem is that the MCU is running on extended IS and then it breaks because it considers that next instructions are extended aswell, but they are not. 

My question here is, can i switch MCU IS execution with assembly (or C) and how? As i understand MCU starts always in normal IS, but it can't switch back from 'extended' to normal only by the hex code output of CC.

Thank you in advance,

  • 0
    Guru 34523 points

    There is no runtime CPU switching between 16-bit / 20-bit. Mixing 16-bit and 20-bit instructions for CPU is not a problem (except some special cases, automatically resolved by C compiler, or in case of assembler source there will be a warning).

  • 0 in reply to zrno soli
    Prodigy 40 points
    How can there be no diference? Won't the MCU decrypt the data differently as the IS is different?

    I tested with guest code as 20bit and both applications (16bit and 20bit, both run ok alone) but when calling the application the 20bit starts but the 16bit does not....

    How does the MCU differentiates from 16/20 bit? Now that you speak of it, maybe it is because of the bootloader calling with:

    void start_program(void){
    void (*StartHolder)(void);
    StartHolder = (void *) *pStartHolder;
    TA1CTL &= MC_0; //Halt Timer
    //Disable All Interrupts
    __disable_interrupt(); //Disable interrupts
    TA1CTL &= ~TAIE; //Disable Timer General Interrupts
    TA1CCTL0 &= ~CCIE; //Disable Timer CCR0 Interrupts
    uart_disableInterrupts(); //Disable USCI_A0 interrupts
    //Clear all interrupt flags?
    disableXT2();

    SYSCTL &= ~SYSRIVECT; //Activate ROM IVT
    //TODO: refedine CLK status to user settings
    asm (" MOV.W #0x05C00, SP"); //Reset Stack Pointer
    ((void (*)())StartHolder)(); //start Code
    //while(1);
    }

    If the processor does not differentiate between 16/20 bit then the problem is in the last call "Start Code" that loads to the PC more than it should?
  • 0 in reply to Diogo Guerra2
    Guru 317940 points
    The CPU has 16-bit and 20-bit instructions, and is always capable of executing all of them. There is no 16-/20-bit mode, as far as the CPU is concerned.

    When you compile a program in 16-bit mode, the compiler just does not use any 20-bit instructions. (It also restricts the program code/data size so that it knows that there will never be a 20-bit address.)

    Even in a 16-bit program, you can use 20-bit instructions with inline assembler, or by telling the compiler explicitly to use 20-bit pointers.

    This looks like a bug in your 16-bit program. What exactly does "stops running" mean? Does a simple LED-blinky test program work?

    Is the bootloader compiled for 20-bit pointers? If yes, it pushes a 20-bit return address on the stack.
  • 0 in reply to Clemens Ladisch
    Prodigy 40 points

    It is not a bug in the program... as the program runs alone (the program is a blink led yes, with nop delays)....
    Stop running mean it jumps to the guest code but then it locks it self in a loop and runs nothing... If i reset, MCU starts with my bootloader as normal

    Take this example

    GuestStart -> [0,1,2,3,4,5,6,7,8,9]
    If this is my ROM memory, that has both IS and DATA, what happens is the following:

    if i run 16bit:
    Bootloader loads PC<- *GuestStart
    Wont the processor start interpreting Instructions as [0,1]; PC+2; execute [2,3]; PC+2; execute [3,4] etc etc

    instead of running as it should [0]; PC+1; [1]; PC+1; [2]; PC+1 ....?

  • 0 in reply to Diogo Guerra2
    Guru 317940 points
    By now, two people have told you that this is not how the CPU behaves. And if you do not believe us, see the instruction format in chapter 6 of the User's Guide.

    What exactly do you mean with "locks itself in a loop"? What loop? What do you actually observe?
  • 0 in reply to Diogo Guerra2
    Guru 34523 points

    Diogo Guerra2 said:
    Stop running mean it jumps to the guest code but then it locks it self in a loop and runs nothing... If i reset, MCU starts with my bootloader as normal

    Maybe slaa600a MSPBoot – Main Memory Bootloader for MSP430 Microcontrollers with source code can help you, to see how jumping to loaded application is done.

**Attention** This is a public forum