vPortStartFirstTask doesn't correctly start task

Kernel
21

Before msr psp, r0 instruction, the value of r0 is 0x34b8. Therefore, the value of PSP after this instruction should be 0x34b8. But that is not the case and the value of PSP remains fffa0 which is not correct.

22

I also just noticed “msr CONTROL, r0” doesn’t write value of r0 to CONTROL. so mrs works but msr does not.

EDIT: also sp register has same value as msp/psp. very weird.

in the manual of M0+ and M1, it says " If the current mode of execution is not privileged, then all attempts to modify any register other than the APSR are ignored". this restriction applies to both msr and mrs. so this should not be a problem, but btw, how to check if it’s privileged or not? any other thing to try for this issue?

EDIT: but in M1 manual, it doesn’t explicitly use the term psp/msp, instead, it uses SP_process and SP_main, not sure why.

23

Bit[0] of the CONTROL register tells the privilege level: Documentation – Arm Developer

In your case, it is zero and so the processor is privileged. What is the possibility of this being a faulty hardware. I will check with my colleagues in the morning.

Thanks.

24

FYI. A bare metal version runs ok with this hardware, blinky LED controlled by interrupt. So less likely a hardware fault.
Thanks very much for your help.

25

From what I can tell from the manufacturer’s site, this is not a physical M1 core but an emulated one, so I wouldn’t be sursprised that this acts differently from a true Cortex M1…

26

uhm, what exactly do you mean by bare metal version?

27

Hi, RAc,
with bare metal version, we directly use hardware driver/hal functions to initialize and set the hardware, NVIC, timer, enable/disable ire, etc, to achieve some simple functions, such as controlling LED.

28

I see, thanks. Next thing I would check, then, if the M1 FPGA emulation is complete. There may be a subset of ARMv6-M instructions not completly rendered on your POD (as you suggested possibly msr). One way to do that would be to add such an instruction via inline assembly to your bare metal app on both your reference M0 and this chip and see how it behaves on either platform.

Needless to say, if that’s your problem, then there’s nothing you can do about it, it’s the manufacturer’s responsibility to be fully compatible.

29

Tested psp and msp again and found msp can be written, while psp can’t.
since CONTROL also can’t be written, and current value of 0 with CONTROL indicates msp will be used as sp.
so changed “msr PSP, r0” to “msr MSP, r0”, it seems working now (ignore “msr, CONTROL, r0” which is supposed to change CONTROL to 0x2 to use psp but it doesn’t). In addition, CONTROL may be controlled by handler mode, which I need to study now.

no more hard fault now, although the LED is not blinking yet.

really appreciate all your guys’ help, RAc, aggarg, retel.

30

This then seems to be issue with FPGA as @RAc mentioned. The changes you made are not correct and FreeRTOS won’t work with these changes.

Thanks.

31

hi, aggarg,

I am not familiar with this. can you explain a little more why using msp won’t work? is it because handler mode has to be used for exception, or because the vector table (isr_table) needs to start at 0x0? or other other reasons? or anyway to confirm this in the code?

it would be great if you could point me to some links for further reading.

thanks

32

one weird issue is that some registers can NOT be written, e.g, after these two steps, the value of these two registers remain “0”. what’s wrong?

portNVIC_SYSTICK_LOAD_REG = ( configCPU_CLOCK_HZ / configTICK_RATE_HZ ) - 1UL;
portNVIC_SYSTICK_CTRL_REG = portNVIC_SYSTICK_CLK_BIT | portNVIC_SYSTICK_INT_BIT | portNVIC_SYSTICK_ENABLE_BIT;

they are defined as:
#define portNVIC_SYSTICK_CTRL_REG ( *( ( volatile uint32_t * ) 0xe000e010 ) )
#define portNVIC_SYSTICK_LOAD_REG ( *( ( volatile uint32_t * ) 0xe000e014 ) )

33

FreeRTOS Cortex-M0 port uses PSP for task stack and MSP for interrupt stack. You can probably write a port with just using MSP but that will be much more work and you will need to write complete context switch code.

At this point, the FPGA you have does not seem to completely implement M1 core. I’d suggest that you check with the hardware vendor about what is implemented and what is not.

Thanks.

34

agree. will verify if the board has all necessary parts implemented.
thanks very much

35

Please keep us updated. Thank you!

36

Update:

We read the vendor’s manual again and think the soft M1 core we are using doesn’t have the necessary registers (E000E010, E000E014, etc). So freeRTOS is not feasible for it.

The manual doesn’t explicitly mention these registers except MSP/PSP. We draw the conclusion by debugging/comparing it with another series which has a different soft M1 core. That M1 core has PSP (based on the manual) and we can write these registers (E010, E014, etc). But that M1 core is not what we are looking for.

1 Like
37

Thank you for taking time to report here.