Baremetal programming

[smishra125]

I am using LPC55S69JBD100 controller of LPCXpresso55S69 Development Board. I am doing baremetal programming and trying to create led blinking project but don't know how to start. I tried to copy CMSIS from arm website but it haven't worked. Since I am beginner in the NXP family, can you send me some links and tutorial to start with the baremetal programming.

I am using MCUXpresso IDE of NXP. 

[smishra125]

@frank_m @ErichStyger I have followed the document and fulfilled all the steps in it. But when i go for the debugging, after the debugger disappears.

I think my board is supporting 55s28 controller not 55s69 that's why it is not been debugged properly. You can see my board in screenshot. I think my development board has both controllers.

Is this LPC55S69-EVK github example https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/MCUXpresso/LPC55S69-EVK/LPC55S69_CM... is compatible with LPC55s28 controller.

[ErichStyger]

I think that board might support both devices, but you have to check what is actually on your board.

[frank_m]

> I think my board is supporting 55s28 controller not 55s69 that's why it is not been debugged properly.

I would think so.
I don't have any LPC55Sxx eval board, but one for a LPC54628 which alternatively supports several MCU variants as well. The one "checkmarked" on the print should be the one you have. But I would cross-check with the label of the MCU.

But generally, Flash / RAM areas of different variants do not match in both size and start addresses. Thus debugging fails already during the flash process.

A pragmatic solution would be to setup the LPCXpresso project again for the 55S28 controller, and continue with this board for the time being..
If you application needs the 55S69, you could have a proper "replacement" board ordered in the meantime.

[smishra125]

@fre Do you have baremetal project example for LPC55S28 controller

[smishra125]

May be this screenshot will help to understand the situation better.

[smishra125]

@frank_m @ErichStyger I have successfully compiled the project and imported the debug folder into McuXpresso IDE. I have done the similar configuration you have said in the link but it shows error as jlink is not connected. Am i missing something as my xpresso board is on default setting or i need to connect the external debugger.

[frank_m]

Can you see the JLink in the device manager (assuming Windows) ?
On Linux, you could use the lsusb command.

The respective drivers should be installed as well.
This installation usually puts Segger tools on your system, check "applications->Segger->J-Link Vn.nn" in your Windows menu.
If it is not there, the driver(s) are probably not installed.

[smishra125]

@frank_m  I think i have installed the jlink software and thinks if the configuration on the board needs to be changed.

[smishra125]

@ErichStyger I am getting the error while running the cmake.init as in screenshot. 

[ErichStyger]

not sure, but it looks like make is not found?

[smishra125]

@ErichStyger  @frank_m Thanks for the support. I will implement it today. 

[ErichStyger]

Hi @smishra125 ,

I recommend you start with the NXP SDK examples (): they are pretty easy to understand, and there is a 'blinky' example too.

Get the SDK from https://mcuxpresso.nxp.com/, drag it into the 'Installed SDK' view of the IDE and start coding. Or use the view: Menu Show > View > Install MCUXpresso SDK.

Use the Import SDK Example from the Quickstart Panel:

Select your board:

then import the 'blinky':

build and debug, and you should have it running.

In case you want to go bare-bare metal with CMake, I wrote about this here: https://mcuoneclipse.com/2022/09/04/tutorial-creating-bare-bare-embedded-projects-with-cmake-with-ec...

But this is more for the Pro, if you are well in CMake and the GNU build tools.

I hope this helps,

Erich

[frank_m]

> I tried to copy CMSIS from arm website but it haven't worked.

ARM's CMSIS only covers the generic part of the core, common to all vendors. You will not find anything specific there.

My recommendation would be to start with the user manual of the MCU (the PDF), and the SDK for your MCU (for the MCUxpresso IDE).

The user manual provides the description of all required core and peripheral registers, and the required sequence(s) to achieve certain functionalities.

The SDK provides example implementation for most of the interesting/relevant use cases.

Starting from there, you could understand and reproduce the functionality of the examples, start to strip it down, and remove code/functionality unnecessary for your application.

However, compared to other environments (e.g. a competitor's tool/IDE named after a 3D geometric object), NXP's SDKs come with very little overhead, and without questionably design framework choices forced upon the user.

In a commercial environment, such bare-metal coding is only oursued when the (often relatively small) gains in performance and size outweights the reduced portability and testability, and increased development time and costs.

[Oxolotol]

I started with a different example, and am trying to port blinky timer to it.  But I can't find where blinky enables the systick interrupt. It's not described in the read me.

[frank_m]

The systick timer, as part of the core, is handled in ARM CMSIS functions.
Usually as a call to SysTick_Config(), which is an inline function implemented in core_cm<x>.h (core_cm4.h in my case).
At least it was last time I used it.

This function enables the interrupt as last step.