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.

CCS/UCD3138128A: Is it necessary to disable interrupt when we enter supervisor mode?

Part Number: UCD3138128A
Other Parts Discussed in Thread: UCD3138

Tool/software: Code Composer Studio

Hello,


We have a requirment that PSU FW can be updated in PSU power on state.

In this case, when code is operating in flash A and recive data from I2C then wirte to flash B.


When we need to write flash ,we need turn into superviser mode. As i know , when we enter supervisor mode it is necessary to disable interrupts.(As below code)

#pragma INTERRUPT(software_interrupt_zoneA,SWI)

void software_interrupt_zoneA(Uint32 arg1, Uint32 arg2, Uint32 arg3, Uint8 swi_number)

{

//make sure interrupts are disabled

        asm(" MRS     r3, cpsr ");                // get psr

        asm(" ORR     r3, r3, #0xc0 "); // set interrupt disables

        asm(" MSR     cpsr, r3");                 // restore psr

     asm("  LDRB  R3,[R14,#-1]"); //get swi number into R3 as fourth operand

Is there have any chance that we skip the step "set interrupt disables".


Because we don't want to disable interrupts which will let our D-D level have risk in protection & dynamic control.

So reference to above describe, is it necessary to disable interrupt when we enter supervisor mode?

  • an expert will help you soon
  • I think at least some of the interrupts are disabled on entry to the software interrupt automatically, so you might actually have to enable them.

    I would suggest trying making the software interrupts fast enough that they don't affect your fault handling, etc.  Remember that the comparator based fault handling shuts things down immediately, with no need for firmware first.

    But if you want to try:

    We haven’t tried it, but it should be relatively safe, with some restrictions.  The software interrupt has its own stack pointer and stack area. 

     

    The restrictions are possible interactions between what the software interrupt is doing, and what the rest of the code is doing.

     

    The biggest potential issue is the old style checksum clear/memory erase to go back to ROM mode.  The EVM codes all just stick the program into the start of RAM.  That will blow up any variables that are in that area.  So any interrupts that use those RAM variables will probably read the wrong thing, and could also write the wrong thing.  So probably the checksum won’t get erased.  

     

    You definitely want to disable the interrupts before doing that software interrupt.  The live switch codes are safe from that because they have a special RAM area to put the program into.

     

    Another issue is that when data flash is being erased or written to, it will return a 0xffffffff when read.  This shouldn’t normally be a problem because we generally read data flash only at start up. Of course if you are going to change the software interrupt to read the busy bit during data flash writes and erase, you need to make sure that data flash isn’t read during busy in background either.

     

    That’s pretty much all I can think of that would cause problems, but there could be more.  As I say, we haven't every tried it. 

  • Basically, we do not try to enable nest interrupt in SVC mode before., if you want, you can still enable it. It should be relatively safe, with some restrictions.

       1. You need to design your SVC stack properly and big enough to enable nest interrupt in SVC mode.

       2. The codes used to erase PFLASH will need to copy to RAM then excecute. Your RAM space must be defined well to make sure your run time variables safe.  If variables are destroyed when you copy code to RAM, your system of course will be dead.

        3. Protections using analog comparators don’t need firmware involve. 

     

    If your code doesn’t design to enable nest interrupt, we recommend you disable nest interrupt in SVC mode, make your software interrupt as short as possible to simplify firmware design.

     

    Since your code architecture is different than ours, it is still your decision to implement it or not. 

  • As I have already said, it is not necessary to disable interrupts when entering the software interrupt.  We just did it to avoid complications, like the ones I have already described. 

    However, we haven't tried it, so there may be other complications that we haven't thought of.

    The ARM default, which happens automatically with a software interrupt, is that normal interrupts are disabled on entering a software interrupt.  Fast interrupts are not disabled. 

    And, as I already mentioned, each interrupt has its own stack pointer, so as long as the stacks are all big enough, you should be safe.

    Of course it is also necessary to not have any variables or peripheral registers that are being written to by more than one level - interrupt or background loop.  If you don't follow this rule, you run the risk of broken writes, where one program reads a value, is interrupted by another level that reads and writes the same value and returns, and then the first program overwrites what the second program wrote.  That's always a risk with any interrupt and any processor. 

  • Ian,
    Just wondering , can CCS compiler with #pragma INTERRUPT can handle necessary context saving when enable nest interrupt in SVC mode or customer need to write their own assembly?
  • Hi Ian,

    I also want to know the answer of Andrew's question. Thank you!

    And I have three more questions as below :

    1. Can we write flash in system mode? Is it have the same "privilege" with  supervisor mode?

    (Reference to below UCD3138 SPEC)

    2. The description of system mode purpose says that system mode "Privileged, using same User mode registers"

    So can we let MCU always keeps in system mode and no need to switch to user mode?

     

    3. Combine question 1 & 2 , if we always keeps MCU in system mode. We can doing the write flash action without switch mode (won't trigger software interrupt and don't get into supervisor mode)

    Is it the correct inference?

     

  • Yes, you can keep the device in system mode and then you can access the flash and flash control registers with no software interrupts  We do it this way in the bootloader.  The reason we don't do it in the power supply code is that it is a slight extra protection against noise causing the processor to get lost.  If it gets lost, it is less likely to damage the flash program if it is in user mode.  As I say, it is probably a slight benefit.

    Nesting interrupts generally is used to describe nesting interrupts of the same type, typically standard interrupts.  For this, the compiler doesn't provide code.

    For running a software interrupt and interrupting it with a fast interrupt, that's not really nesting, and the compiler should provide code for that.  Basically the fast interrupt will push any general registers that it uses, and will then pop them before it returns.  And the ARM 7 automatically saves the processor status register and restores it when it returns.