0

LPC11xx Cortex-M0 FreeRTOS v7.0.0 using GCC (CodeRed)

Dave Nadler

July 20, 2011 15:47

None

Follow

This Cortex-M0 port was developed by taking the official v7.0.0 ARM_CM3/port.c and:
- merging in M0 changes from older NXP 5.3 port (replace M3 instructions not available on M0),
- fix a number of bugs in the original NXP version.

Where the NXP 2010 version quickly crashes under stress, this version appears reliable.

Testing was with the CodeRed toolchain provided by NXP;
should work directly with other GCC-based toolchains.

Only affected file: port.c

Please contact me with any questions, bug-fixes, etc !
Best Regards, Dave

FreeRTOSV7.0.0_ARM_CM0_portable_20010720.zip

• Facebook
• Twitter
• LinkedIn

47 comments

• 0
  
  Patrick July 21, 2011 06:51

  >Where the NXP 2010 version quickly crashes under stress, this version appears reliable.

  Which one are your referring to?  Older versions (5.3/M0) indeed had an issue with ISRs. That was fixed in spring 2010 already.

• 0
  
  Richard Barry July 21, 2011 07:06

  I don't want to muddy the water here.  The port in question is not yet official, but there will be an official CM0 port soon, so it is of interest.  I have not looked at the modifications made by Dave N yet, or looked at which version it was based on, but the following is a snippet from a separate support thread on the same topic (the CM0 code) that you may or may not have seen, and may or may not be useful:

  [actually, I attached it as a file, as the formatting was being messed up here]

• 0
  
  Dave Nadler July 21, 2011 12:52

  Patrick: The buggy M0 port.c is posted on NXP's website here:
  http://ics.nxp.com/support/lpcxpresso/zip/examples.freertos.lpc1114.zip
  Link is labeled "Example Project: FreeRTOS Example Project for LPC1114" on page:
  http://ics.nxp.com/support/lpcxpresso/

  IIRC this is also included in CodeRed's latest distribution as of July 2011
  Readme says: NXP LPCXpresso LPC1114 FreeRTOS Example V1.0 7/6/2010

  Only comment in port.c says:
      FreeRTOS.org V5.3.0 - Copyright (C) 2003-2009 Richard Barry.

  Hope that helps,
  Best Regards, Dave

• 0
  
  Dave Nadler July 21, 2011 12:57

  Richard - I must be being dense, but I'm baffled by that comment.

  If the initial stack pointer address in the vector table is wrong:
  - why isn't this just fixed in the link file ?
  - how can this thing even boot (or is it just wrapping to a random address) ?

  In my build the vector entry is:    0x10002000     _vStackTop = _vRamTop
  seems to be doing the correct thing...

  Sorry I don't understand,
  Best Regards, Dave
  
  
  

• 0
  
  Dave Nadler July 21, 2011 12:59

  Is this comment trying to say:

  "The value fetched from the reset vector must be decremented before use" ?

  Thanks again !
  Best Regards, Dave

• 0
  
  Jim Leifker July 21, 2011 14:21

  Hi Dave,

  Note this pertains to the port from NXP website not your port.

  If I am not mistaking.

  The stack grows downwards, and the SP points to the last entry on the stack. ( ARM Information Center )
  When something is pushed onto the stack the SP is decremented then data stored at that location.  So the first item pushed onto the stack will be at address (0x10002000-4) = 0x10001FFC
  
  In the port the link register R14 is being saved to the address 0x10002000 before decrementing the address by 4. Note this has nothing to do with SP itself. To write R14 to first stack location the address 0x10002000 must be decremented by 4 so R14 is placed at (0x10002000-4) = 0x10001FFC just as if R14 was pushed onto the stack.
  
  To mask this problem the linker file can be changed to start the stack pointer at 0x10001FFC but the first item pushed onto the stack will be at 0x10001FF8 and str r4,[r0] will still write to 0x10001FFC having the potential of overwriting a variable stored there in the future.
  
  

• 0
  
  Jim Leifker July 21, 2011 14:41

  In my build the vector entry is:    0x10002000     _vStackTop = _vRamTop

  Yes this is correct.

• 0
  
  Dave Nadler July 21, 2011 15:44

  There are several places in the M0 port I've posted that reference the
  reset-stack-pointer. I believe, but I am not absolutely sure, that the stack
  pointer will always be decremented prior to anything being stored on
  the stack...

  Thanks for the clarification,
  Best Regards, Dave

• 0
  
  Jim Leifker July 21, 2011 16:41

  My edit to the NXP port.c
  I added two lines of code to port.c see xPortPendSVHandler( void ) below.
  " sub r0, #4        \n" /* !!!
  
  This is working for me. Let me know what you think.
  I also noticed that the NXP port uses the main stack pointer (msp) and your port uses (psp), can you explain? I would like to better understand one vs the other.   Thanks.
  
  FYI My linker file:
  MEMORY
  {
    /* Define each memory region */
    MFlash32 (rx) : ORIGIN = 0x0, LENGTH = 0x8000 /* 32k */
    RamLoc8 (rwx) : ORIGIN = 0x10000000, LENGTH = 0x2000 /* 8k bytes */
  
  }
    /* Define a symbol for the top of each memory region */
    __top_MFlash32 = 0x0 + 0x8000;
    __top_RamLoc8 = 0x10000000 + 0x2000;
  
  
  void xPortPendSVHandler( void )
  {
      /* This is a naked function. */
      __asm volatile(
                      " mrs r0, msp       \n"
                      "                   \n"
                      " ldr r3, pxCurrentTCBConst \n" /* Get the location of the current TCB. */
                      " ldr r2, [r3]      \n"
                      "                   \n" /* Save the remaining registers. */
                      " sub r0, #4        \n"
                      " str r7, [r0]      \n" /* Save r7 */
                      " sub r0, #4        \n"
                      " str r6, [r0]      \n" /* Save r6 */
                      " sub r0, #4        \n"
                      " str r5, [r0]      \n" /* Save r5 */
                      " sub r0, #4        \n"
                      " str r4, [r0]      \n" /* Save r4 */
                      "                   \n"
                      " mov r4, r8        \n"
                      " mov r5, r9        \n"
                      " mov r6, r10       \n"
                      " mov r7, r11       \n"
                      " sub r0, #4        \n"
                      " str r7, [r0]      \n" /* Save r11 */
                      " sub r0, #4        \n"
                      " str r6, [r0]      \n" /* Save r10 */
                      " sub r0, #4        \n"
                      " str r5, [r0]      \n" /* Save r9 */
                      " sub r0, #4        \n"
                      " str r4, [r0]      \n" /* Save r8 */
                      "                   \n"
                      " str r0, [r2]      \n" /* Save the new top of stack into the first member of the TCB. */
                      "                   \n"
                      " ldr r0, =0x0      \n" /* cm0 has fixed vector table at address 0x0 */
                      " ldr r0, [r0]      \n" /* !! Get top of stack address 0x10002000  ( Remember RAM is 0x10000000 - 0x10001FFF ) 8K
                      " sub r0, #4        \n" /* !!! 0x10002000 - 4 = 0x10001FFC Store R14 (4 bytes) in RAM at address 0x10001FFC */
                      " mov r4, r14       \n"
                      " str r4, [r0]      \n" /* Save r14 */
                      " msr msp, r0       \n" /* Set the msp back to the start of the stack. */
                      "                   \n"
                      " mov r0, %0        \n"
                      " msr basepri, r0   \n"
                      " bl vTaskSwitchContext \n"
                      " mov r0, #0        \n"
                      " msr basepri, r0   \n"
                      "                   \n"
                      " ldr r0, =0x0      \n" /* cm0 has fixed vector table at address 0x0 */
                      " ldr r0, [r0]      \n" /* !! Get top of stack address 0x10002000  ( Remember RAM is 0x10000000 - 0x10001FFF ) 8K
                      " sub r0, #4        \n" /* !!! 0x10002000 -4 = 0x10001FFC Retreive R14 (4 bytes) from RAM at adddress 0x10001FFC */
                      " ldr r4, [r0]      \n" /* Restore r14 */
                      " mov r14,r4        \n"
                      "                   \n" /* Restore the context, including the critical nesting count. */
                      " ldr r3, pxCurrentTCBConst \n" /* Get the location of the current TCB. */
                      " ldr r1, [r3]      \n"
                      " ldr r0, [r1]      \n" /* The first item in pxCurrentTCB is the task top of stack. */
                      "                   \n" /* Pop the registers. */
                      " ldm r0!, {r4-r7}  \n" /* Pop r8-r11 */
                      " mov r8,  r4       \n"
                      " mov r9,  r5       \n"
                      " mov r10, r6       \n"
                      " mov r11, r7       \n"
                      " ldm r0!, {r4-r7}  \n" /* Pop r4-r7 */
                      " msr msp, r0       \n"
                      " bx  r14           \n"
                      "                   \n"
                      " .align 2          \n"
                      "pxCurrentTCBConst: .word pxCurrentTCB  \n"
                      ::"i"(configMAX_SYSCALL_INTERRUPT_PRIORITY)
                  );
  }
  
  
  

• 0
  
  Dave Nadler July 21, 2011 18:01

  Hi Jim - Looks like my version needs that sub as well
  as [r0] is used directly before any decrement/push.

  PSP is recommended for normal "thread" operation,
  while MSP is used for faults. M3 port uses PSP.
  Please see my comments in port.c; there is a lot
  more detail there...

  Can you send me your complete port.c so I can
  do a comparison (Dave[dot]Nadler[at]Nadler[dot]com) ?

  Thanks for the tips !
  Best Regards, Dave

• 0
  
  Richard Barry July 21, 2011 18:07

  I've been out of the office so just catching up with this thread.

  With reference to the post above, I believe you can attach the file to the post, rather than email it. 

  Just on an admin front, I prefer email addresses not to be posted in plain text as it attracts spam bots.  I am going to edit it slightly, don't be offended!

  Regards.

• 0
  
  Jim Leifker July 21, 2011 19:40

  The attached port.c is the same as the one located in LPCXpresso Example Projects for LPC11C24 V2.0 (Jan 27, 2011)  at  http://ics.nxp.com/support/lpcxpresso/

  Including two additions of   " sub r0, #4        \n" /* !!!

   

  I noticed that I forgot to end the comment with */    I typed in the comment while posting, the code has the */

• 0
  
  Dave Nadler July 23, 2011 01:14

  Hi Jim - I tried adding the two sub instructions and it stopped working;
  maybe I broke something else. Unfortunately I'm leaving on a trip
  for around a month; occasional email but no debug setup with me.

  I'll chase this a bit more when I get back in mid August.

  Thanks for the tips,
  Best Regards, Dave

• 0
  
  Jim Leifker July 23, 2011 16:25

  Hi Dave - I will try your port and keep you up to date if I find anything.

• 0
  
  Dave Nadler July 24, 2011 02:44

  Great - FYI, here's the broken version where I attempted to merge your "sub"...
  I've tried to comment purpose of various steps...

  Thanks,
  Best Regards, Dave

• 0
  
  Giancarlo July 29, 2011 13:37

  Hi All,

  I would like to add a comment on this last port contributed.

  Within the port.c file, I noticed that the code still uses code like:

  " mov r0, #0            \n"
  " msr basepri, r0       \n"

  if I got it right, this on Cortex-M3 is to make sure within xPortPendSVHandler() there is no preemption during the context switch (vTaskSwitchContext ) from any ISR handled within the OS.

  On Cortex-M3 the BASEPRI register is used and put equal to configMAX_SYSCALL_INTERRUPT_PRIORITY.

  In this way all interrupts handled by the Os are masked, since they are defined in the range  [configMAX_SYSCALL_INTERRUPT_PRIORITY - configKERNEL_INTERRUPT_PRIORITY], whereas other real time interrupts (with higher priority that the Os) can still be handled (but these are not allowed by definition to call any RTOS APIs).

  On Cortex-M0 architecture the BASEPRI register is *not* implemented, which means you can only disable interrupts globally via PRIMASK. So using BASEPRI, at least has no effect on the processor.

  Still, I am not sure if this is an open issue, imagine different priority levels are used within the Os, like in such a scenario:

  #define configKERNEL_INTERRUPT_PRIORITY            3

  #define configMAX_SYSCALL_INTERRUPT_PRIORITY    2

  Within xPortPendSVHandler() interrupts defined at priority level 2 would still be served even though the xPortPendSVHandler would like to process "bl vTaskSwitchContext" without being preempted.

  This is not what the implementation would expect, in my understanding.

  So I am not sure if it would have to be replaced by something like:

  cpsie i / cpsid i

  (to enable / disable) interrupts globally

   

  Best regards,

  Giancarlo

   

   

• 0
  
  Jim Leifker July 30, 2011 21:22

  Hi Giancarlo,
  
  That's what I thought when reading about the PRIMASK and BASEPRI.
  
  I fixed port.c_hangs stack issue and included the PRIMASK change.
  The section of code that saves R14, branches to vTaskSwitchContext, then restores R14 has to be done on the MSP not the PSP.

  You can compare the two ports to see the difference.  To compare files I like to use http://winmerge.org/

• 0
  
  Jim Leifker July 31, 2011 15:18

  File: "port_20110731.c"   that is port_YYYYMMDD.c
  I took a copy of the original port and added / deleted some comments, justified some assembly syntax.
  Implement previous stack fixes.
  Implement "cpsie i" and "cpsid i" to enable disable interrupts using PRIMASK instead of BASEMASK.
  Initialized PSP and MSP to top of stack before kicking off the tasks in In vPortStartFirstTask().
  Removed the debug_printf's.
  Removed the checking if PSP is set because vPortStartFirstTask() is only called once and if it's already set
  it shouldn't hurt setting it again.
  
  Regards, Jim

• 0
  
  Oussema Hajjem August 11, 2011 10:12

  hi 

  please i need a demo for the EM773 CORTEX-M0 if it is available

  I'm new i really need help

  thanks;

• 0
  
  Mike Newsome August 12, 2011 09:05

  Many thanks for all who contribute to this forum.

  I am attempting to implement a FreeRTOS port on anNXP  LPC11xx Cortex M0, and have to use the Keil uVision4 toolchain. I am having some reliability problems with the version of portable code I have generated. I am not an M0 expert, although I used FreeRTOS with and ARM7 device (at9sam7...) very satisfactorily.

  I have now taken the two port.c offerings above and studied them carefully. After trying to translate them into a suitable form for the RealView tools, I am presently left with one problem:

      secondly the end of xPortPendSVHandler is the line '::"i"(configMAX_SYSCALL_INTERRUPT_PRIORITY)' which I simply don't understand. Any help would be gratefully received.

  Secondly, I see in the ARM documentation a comment that 'When changing the stack pointer, software must use an ISB instruction immediately after the MSR instruction. This ensures that instructions after the ISB execute using the new stack pointer. See ISB.' Presumably this only applies if work needs to be done using the stack, before the end of the excption?

  Finally, I am still unclear about the temporary storing of R14 at the top of the main stack. Sometimes I persuade myself this is safe, others that it may (occasionally) cause trouble. Exceptions (which I would regard as interrupts) use this stack, and this bit of code runs in an interrupt, thus causing corruption of the return stack. COuld someone help with this please?

  Many thanks for all your time

  Mike

• 0
  
  Giancarlo August 12, 2011 11:54

  Hi Mike,

  secondly the end of xPortPendSVHandler is the line '::"i"(configMAX_SYSCALL_INTERRUPT_PRIORITY)' which I simply don't understand. Any help would be gratefully received.

  
  

  this was used to pass configMAX_SYSCALL_INTERRUPT_PRIORITY as a parameter to the CortexM3 assembly routine port

  mov r0, %0 
  msr basepri, r0

  it can be removed since it is of no usage here

   

  regarding the ISB instruction, this is more for compatibility with other CortexProcessors like the M3, if you need to run the code on them also. Use of ISB after changing the stack (after changing the CONTROL register) is recommended by ARM (shall be used). However it should not cause an issue, since the M0 has only one bus interface, and there is no write buffering. So there should not be any concurrency, race, or instruction reordering in the architecture.

   

  I am still unclear about the temporary storing of R14 at the top of the main stack

  I understood that it would be required since within the PendSV exception handler, you call the kernel vTaskSwitchContext function, so better should preserve the content of the link register. The link register gets a special value when an exception is entered, so that when pushing it back to the PC during unstacking the processor knows it is returning from an exception. When the vTaskSwitchContextfunction is called with a BL, the value of LR is overwritten with the address of the next (return) instruction.

  I believe the (MSP) stack would not be corrupted, as long as you push the LR and pop it back (like the M3 port does)

  see also:

  http://www.freertos.org/index.html?http://interactive.freertos.org/entries/20321067-lpc11xx-cortex-m0-freertos-v7-0-1-using-lpcxpresso

  it should include a fix also for disabling interrupts around vTaskSwitchContext, since this function in my understanding should not be interrupted (can be done only globally on M0, though, and not via PRIMASK like on M3)

   

  Kind regards,

  Giancarlo

• 0
  
  Mike Newsome August 12, 2011 11:55

  OK, Ive discovered about the last line (::"i(....)) - it seems to be a funny for the gcc embedded assembler to tell the compiler what has been changed, but Im still troubled by my second and final concerns above.

   

  Regards, Mike

• 0
  
  Dave Nadler August 19, 2011 19:14

  I'm back from my travels and starting to look at this project again,
  Thanks to all that have contributed in my absence.

  Quick, possibly dumb question:

  Why is the stack-top address fetched from the vector table, rather
  than just resolved at link time in the same fashion this address is
  filled in the vector table in the first place ?

  In particular: &_vStackTop, // The initial stack pointer

  Seems like more instructions and complexity than necessary ?

  Thanks in advance,
  Best Regards, Dave

• 0
  
  Jim Leifker August 20, 2011 05:31

  Welcome back, Dave.
  
  I was having a problem when asigning priority levels to interrupts.
  I tried Giancarlo's port and it worked. I found that if I replaced the section of
  code below in xPortPendSVHandler() with code from Giancarlo's port, it worked.
  
  
  REPLACE:
  
          " ldr r0, =0x00                 \n" /* cm0 has fixed vector table at address 0x00000000 */
          " ldr r0, [r0]                  \n" /* Fetch the initial stack pointer from the first entry in vector table. Note initial stack pointer is typically 0x10002000 for 8K RAM 0x10000000-0x10001FFF */
          " sub r0, #4                    \n" /* Decrement stack pointer to point to actual memory prior to storing anything. */
          " mov r4, r14                   \n" /* Get a copy of the R14 Link Register in R4 */
          " str r4, [r0]                  \n" /* Store Link register at top of stack */
          " msr msp, r0                   \n" /* Store new top of stack into MSP before calling vTaskSwitchContext. */
          "                               \n" /* */
          " cpsid i                       \n" /* Disable all interrupts except NMI (set PRIMASK) */
          " bl vTaskSwitchContext         \n" /* Call vTaskSwitchContext using MSP. */
          " cpsie i                       \n" /* Enable interrupts (clear PRIMASK) */
          "                               \n" /* The next few steps restore R14 stored at top of stack and resets MSP back to initial stack pointer. */
          " ldr r0, =0x00                 \n" /* cm0 has fixed vector table at address 0x00000000 */
          " ldr r0, [r0]                  \n" /* Fetch the initial stack pointer from the first entry in vector table. */
          " msr msp, r0                   \n" /* Set MSP back to top of stack ready for next handler call. */
          " sub r0, #4                    \n" /* Decrement stack pointer to point to actual memory prior to reading anything. */
          " ldr r4, [r0]                  \n" /* Get Link Register from top of stack. */
          " mov r14, r4                   \n" /* Store Link Register into register R14 */
  
  WITH:
  
      " push {r14}            \n" /* backup r14 on the main stack MSP */
          "                               \n" /* LR has special value since we are within an exception */
          " cpsid i                       \n" /* Disable all interrupts except NMI (set PRIMASK) */
          " bl vTaskSwitchContext         \n" /* Call vTaskSwitchContext using MSP since we are in exception handler */
          " cpsie i                       \n" /* Enable interrupts (clear PRIMASK) */
          "                               \n"         
          " ldr r3, [SP]            \n" /* get back LR from MSP, adjust MSP */
          " add SP, #4            \n"
          " mov r14, r3            \n" /* restore LR contents */
  
  

• 0
  
  Giancarlo August 20, 2011 11:05

  Hi Jim,

  good to know that you could further test the port, and it seems working. Note there is another project with the most recent version of it on the site (for rtos 7.0.1)

   

  Dave,

  I guess you refer to :

  void vPortStartFirstTask( void )
  {
      __asm volatile (
       " ldr r0, =0x00   \n" /* cm0 has fixed vector table at address 0x00000000 after reset */
          " ldr r0, [r0]    \n" /* Fetch the the initial stack pointer */
          " msr msp, r0     \n" /* Set MSP back to top of stack, will invalidate original stack contents */

   

  well, you might save one ldr instruction,at least. I would have to double-check if msr allows to load directly an external symbol, used as a label, so that you could save also the loading into the register (I fear not...). Still, this is run at startup only once so it would not really add any overhead to the task switch.

  I guess done in this way it is a bit more portable, since typically linker defined / exported symbols and their syntax is highly toolchain dependent. I realized in the past that some use cases are either unsupported, or handled differently, especially when talking about the assembler (typically compilers can support linker defined symbols in a much easier way, although the syntax might be again sligtly different). So you might do it differently, but you would have to clutter the code with a lot of #defines which are compiler dependant, or add a specific header file which defines the external symbols, then includes them in the assembly - and there's where the toolchains might bite you back ;-)  So it's in theory possible, but much work for, well, little return- just a thought.

  Giancarlo

• 0
  
  Jim Leifker August 21, 2011 02:17

  Hi Giancarlo,
  
  Actually I have been using the new version for several weeks now with no problems. :)
  Out of curiosity i wanted to know which part of the old port was failing.
  
  Thanks for the great work!

• 0
  
  Mike Newsome August 22, 2011 07:57

  Hello All

  The hardware provides for the 'top of stack' to be loaded from address zero at reset, so no code is needed there, and any toolchain which supports the M0 will do that. The code to read it back is very trivial when we need it elsewhere, much easier than trying to copy the vector table stuff, and portable between tools.

   

  I have been using Giancarlo's modification for a short while, with no problems on a LPC1114.

   

  Best regards

  Mike

• 0
  
  Dave Nadler August 23, 2011 18:24

  Hi All - Attached is the file set I'm using now. This is basically
  Giancarlo's version (including corrected portmacro.h) plus documentation.

  Works great with 7.0.1, LPCXpresso 3.6.3, LPC11xx.

  Thanks for the help,
  Best Regards, Dave

• 0
  
  Mike Newsome August 24, 2011 09:22

  Hello Dave,

  I am not sure if this is place to do it, but I have 'ported' your port.c (and portmacro.h) to the Realview (Keil) compiler and uVision IDE. The attached has your Code RedLPCXpresso  version also.

  The RVDS has slightly different assembler possibilities!

• 0
  
  Dave Nadler August 24, 2011 11:07

  Thanks ! There were a couple of points in the code I was tempted to polish,
  but I was defeated by the "uniform assembly language" syntax... Easier using
  T2 instructions but not that important...

  Richard will no doubt do a bit better !

  Thanks again to all especially Giancarlo,
  Best Regards, Dave