mr68360 wrote on Thursday, November 05, 2015:
The ARM documentation lists three System Handler Priority Registers: SHPR1, SHPR2, SHPR3. SHPR3, the register controlling SysTick and PendSV, is at address 0xe000ed20.
Address 0xe000ed20, however, is defined in FreeRTOS 8.2.3 as portNVIC_SYSPRI2_REG. Is the intent of the #define to reflect the register’s ordinality (SYSPRI3 ??). If so, it would be more accurate to call this macro portNVIC_SYSPRI3_REG.
Code maintainers please note.
rtel wrote on Thursday, November 05, 2015:
I’ve just been looking at this.
As you say there are three such registers, and they appear in order at addresses 0xe000ed18, 0xe000ed1c and 0xe000ed20.
portNVIC_SYSPRI2_REG |= portNVIC_PENDSV_PRI;
portNVIC_SYSPRI2_REG |= portNVIC_SYSTICK_PRI;
…are, as you say writing to 0xe000ed20. If 0xe000ed18 is syspri 0, 0xe000ed1c is syspri 1, then 0xe000ed20 would be syspri 2.
I cannot see the name SHPR3 being used in the Cortex-M technical reference manual. Where does that register name come from?
I found this question raising what I have just found and thought to be an issue, so replying to this. Sys Handler Pri Register is starting from 1 rather than 0, and I see the Sys Handler Pri Reg 3 here in the reference manual https://developer.arm.com/documentation/100166/0001/system-control/system-control-registers
with these defines
|0xE000ED18|SHPR1|RW|0x00000000|System Handler Priority Register 1|
|0xE000ED1C|SHPR2|RW|0x00000000|System Handler Priority Register 2|
|0xE000ED20|SHPR3|RW|0x00000000|System Handler Priority Register 3|
I found the issue when referencing the ATSAM4E8 datasheet and trying to decide between the which port CM4F or CM4_MPU to use (v.10 up) , but both seem to label the Sys Pri register incorrectly. (Side note: the comment in port.c for ARM_CM4_MPU still references CM3.)
Thank you for pointing it out. Agree, that the following #define should be named
portNVIC_SHPR3_REG to be better aligned with ARM documentation.
#define portNVIC_SYSPRI2_REG ( *( ( volatile uint32_t * ) 0xe000ed20 ) )
0xe000ed20, however, is correct and the port will work correctly. We will fix the naming.
Whether you choose CM4F or CM4_MPU port depends on whether you want to use Memory Protection Unit (MPU).
Regarding the mention of CM3 in the comments in CM4_MPU port, we will fix that too.
Both the issues have been addressed in the following PRs:
Thank you for reporting these issues.