LPC1769 using LPCXpresso IDE

[fjarnjak]

Hello all,

I haven't posted for a while due to being busy @ work and I see there is a new release out - cool

I am currently trying to run a ChibiOS on a LPCXpresso 1769 board using LPCXpresso IDE as a project management and build system.
There are some difficulties in organizing a project into many sub-folders and for it to compile....therefore I have a main folder with my main.c file and ChibiOSAll sub-folder which has all the files relevant to the LPC1769 Cortex M3 MCU.

Once LPCXpresso IDE makes a project, it by default makes all the startup code files, vectors and the like so I didn't use those from ChibiOS. I will rely on them from LPCXpresso IDE since I know they work (did many bare-metal projects).

What I did change is that in chcore_v7m.c name of SysTick handler from Chibi distribution is different as in LPCXpresso IDE vectors, so I have changed the name:

CH_IRQ_HANDLER(SysTick_Handler) { and not SysTickVector.

Same with

Code: Select all

SVCall_Handler(void)

and not

Code: Select all

SVCallVector

, etc.

Second, LPCXpresso IDE and its compiler options / linker scripts do not provide __heap_base_ and __heap_end_ but they provide other vars:
so I have modified them to be able to compile:

Code: Select all

void _core_init(void) {
#if CH_MEMCORE_SIZE == 0
  //extern uint8_t __heap_base__[];
  //extern uint8_t __heap_end__[];
  //nextmem = (uint8_t *)MEM_ALIGN_NEXT(__heap_base__);
  //endmem = (uint8_t *)MEM_ALIGN_PREV(__heap_end__);
   extern uint8_t _pvHeapStart[];
   extern uint8_t __end_of_heap[];
   nextmem = (uint8_t *)MEM_ALIGN_NEXT(_pvHeapStart);
   endmem = (uint8_t *)MEM_ALIGN_PREV(__end_of_heap);
#else
  static stkalign_t buffer[MEM_ALIGN_NEXT(CH_MEMCORE_SIZE)/MEM_ALIGN_SIZE];
  nextmem = (uint8_t *)&buffer[0];
  endmem = (uint8_t *)&buffer[MEM_ALIGN_NEXT(CH_MEMCORE_SIZE)/MEM_ALIGN_SIZE];
#endif
}


When I stepped with debugger I see that start is 268435880 and end is 268435872 meaning 8 bytes....??????? Something is wrong. Maybe I can use CH_MEMCORE_SIZE some larger number (say 1024) and forget about dynamic allocation.

After that I have copied all other files, and ChibiOS compiles well. I did not do anything with HAL now and all other subsystems.

In main.c at the beginning I would start SysTick timer and later on I would start ChibiOS.

However, the thing does not work......in main, when I call sleep, it never returns; I stepped with debugger from reset, and things seems fine; when sleep is called idle thread takes over and there it sits in port_wait_for_interrupt in that while loop. I did put a SysTick_Handler breakpoint and one time I got a hit, it executed all the methods there but went into a HardFault handler.

Any ideas?

In main below I didn't even bother with threads, because when I tried first, they execute and once they hit sleep they also break.

My main:

Code: Select all


int main(void) {
   
   uint32_t dummy = 0;

   // TODO: insert code here

   while(dummy<5000000)
   {
      dummy++;
   }

   SystemCoreClockUpdate();
   SysTick_Config(SystemCoreClock/1000);

   unsigned long ulLEDState;

   // Enter an infinite loop, just incrementing a counter
   volatile static int i = 0 ;

   SetupIO();
   Setup7SegmentSPI();

   LPC_PINCON->PINSEL1   &= ( ~( 3 << 12 ) );
   LPC_GPIO0->FIODIR |= ( 1 << mainLED_BIT );

   chSysInit();

   /*
    * Creates the blinker threads.
    */
   //chThdCreateStatic(waThread1, sizeof(waThread1), NORMALPRIO, Thread1, NULL);
   //chThdCreateStatic(waThread2, sizeof(waThread2), NORMALPRIO, Thread2, NULL);

   i = 0;

   while (TRUE) {
      ulLEDState = LPC_GPIO0->FIOPIN;

      /* Turn the LED off if it was on, and on if it was off. */
      LPC_GPIO0->FIOCLR = ulLEDState & ( 1 << mainLED_BIT );
      LPC_GPIO0->FIOSET = ( ( ~ulLEDState ) & ( 1 << mainLED_BIT ) );
       chThdSleepMilliseconds(500);
      for(ulLEDState = 0; ulLEDState < 2000000; ++ ulLEDState);
     i = (i + 1) & 15;
   }

   return 0 ;
}



[fjarnjak]

I debugged some more and it seems after SysTick Handler is processed in epilogue when it hits:

Code: Select all

 if (chSchIsPreemptionRequired()) {
      /* Preemption is required we need to enforce a context switch.*/
      ctxp->pc = _port_switch_from_isr;


it goes to hard fault handler.

Code: Select all

/**
 * @brief   Excludes the default @p chSchIsPreemptionRequired()implementation.
 */
#define PORT_OPTIMIZED_ISPREEMPTIONREQUIRED

#if (CH_TIME_QUANTUM > 0) || defined(__DOXYGEN__)
/**
 * @brief   Inlineable version of this kernel function.
 */
#define chSchIsPreemptionRequired()                                         \
  (rlist.r_preempt ? firstprio(&rlist.r_queue) > currp->p_prio :            \
                     firstprio(&rlist.r_queue) >= currp->p_prio)
#else /* CH_TIME_QUANTUM == 0 */
#define chSchIsPreemptionRequired()                                         \
  (firstprio(&rlist.r_queue) > currp->p_prio)
#endif /* CH_TIME_QUANTUM == 0 */

#endif /* _FROM_ASM_ */

#endif /* _CHCORE_H_ */


This one executes (optimized).

[Giovanni]

Hi,

It is possible that the startup files you are using don't setup the CPU in the state required by ChibiOS (properly allocated and aligned dual stacks, privileged thread state, interrupts disabled on main() entry). You should read the documentation regarding the integration requirements of the Cortex-Mx port.

I have an LPCXpresso 1769 lying somewhere and I plan is to support it in some next release however the OS will provide startup and vectors like for all other platforms, the demos will be Makefile-based (which can be imported in Eclipse anyway).

Giovanni

[fjarnjak]

FreeRTOS is being highly advertised on NXP and tightly integrated into the IDE if you ever download and import it into the workspace.
So when you select "New Project" apart from regular C/C++ project (select MCU and so on with project wizzard) you can also select a "FreeRTOS" project and it will make a project with all the settings and you just need to code.

Many people like LPCXpresso and IDE because you get an out of the box solution so you can concentrate on solving a project and going home at the end of the work day and not spending weeks in setting the system up. That's why CMSIS was I guess created; or Atmel's library for higher-end AVRs, etc.

I am not sure importing a Makefile project with this free version of IDE will work as elegantly.

My idea is to use files created by LPCXpresso system project wizzard (starts up and gets me to main()) - I only need to get kernel core working and being able to use threads, mutex, semaphore, sleep and things like that + being able to handle various perhipheral interrupts without crashing RTOS. With this only tasking core working, I can implement basically everything using CMSIS.

Same thing with say Rowley Crossworks - wizzard, Next next, next - Finish and start coding...

I will work on this some more and will report if I find something...

Hi,

It is possible that the startup files you are using don't setup the CPU in the state required by ChibiOS (properly allocated and aligned dual stacks, privileged thread state, interrupts disabled on main() entry). You should read the documentation regarding the integration requirements of the Cortex-Mx port.

I have an LPCXpresso 1769 lying somewhere and I plan is to support it in some next release however the OS will provide startup and vectors like for all other platforms, the demos will be Makefile-based (which can be imported in Eclipse anyway).

Giovanni

[Giovanni]

There is who packaged the OS as an Arduino library, binary libraries and other ways, there is nothing preventing that. The OS is designed to be modular.

It is just that I prefer to provide a self contained environment in order to have all the variables under control, imagine the support and maintenance nightmare of having to maintain the integration with N heterogeneous IDEs with their versions changing all time.

Giovanni

[Badger]

Hi Giovanni,

was there any progress on LPC1769 support?

I think it would be interesting to run chibios on a smoothieboard, which is coming out in the next few weeks.

[Giovanni]

I have an LPCXpresso with LPC1769 already but I never find the time to get started with that one, if you want to try to start a port I could help and test. The first step would be to assess how much different is the clock tree from the LPC13xx which is already supported.

Giovanni

[jcw]

I'd be interested to hear whether there has been any progress on this - several boards use the LPC1769.

-jcw

[Giovanni]

Hi,

Currently there is another maintainer for the NXP side of the project, he already added support for new subfamilies, I don't know if he is planning support for the LPC1769. Probably I should donate that board to him.

Moving this thread in the LPC forum, let's hear his opinion.

Giovanni

[theShed]

Pop it in the post and I'll see what I can do...

As it appears to have a huge number of peripherals anyone have a request for which ones to start with?
(after the usual GPIO/UART).

--
mike