Exercise to add LPC55S69 board support about nxp_sensor_sdk

[kydando]

@RobertRostohar we are getting Linker errors with 55S69 project.
I looked at differences. One area I did not know what to do was the scatter file. I pulled the .scf from another 55S69 SDK. It provided the 3 memory files but not a generic scf like you have for 54114.
Where do you get this file? Did I select the correct files?
Also, I did not know the proper name for the RTE device sub folder. After running the build I saw I chose wrong. And replaced. Just curious where I would determine the name of the folder.
Another odd warning is that the 55S69 project requires the CMSIS DrIver:i2c:custom. While the 54114 did not provide the same convert warnings. Why would this device depend on the custom pack. Trying to understand the reason for the different requirements.
Thanks

[RobertRostohar]

@purdurnr, comment regarding your observations:

1. board file lpc55s69.c uses components (including defines) from the corresponding DFP/BSP packs and should be compatible with them (pack versions are specified in the project solution yml file). It would be desired that a newer pack is still backward compatible.
2. Specific board layer should cover a fixed configuration, exposing I2C either on default I2C Arduino pins or on alternate pins. This includes configuration of I2C peripheral and pins on the device side. Exposing I2C to a different pin would imply a different board layer variant. Jumpers that select which I2C is being used for a sensor are on the shield and covered in the shield layer yml file. When a board exposes I2C on default location the shield needs to select the correct jumper.
3. I'm assuming that board.c is configured and generated by MCUXpresso generator. If that tool supports generating the required code also for Arduino, then the corresponding code from LPC55S69.c/h can be moved there. csolution should support also generator workflow (not sure about the current status). A board layer should however already be pre-configured using the generator and described with connections what is consumed/provided. In this way the csolution can figure out compatible layer. Eventually user could also update the layer in a later step (also using the generator) however the layer compatibility is now the responsibility of the user who changed the layer.

[RobertRostohar]

@kydando. I have looked at your dando-dev branch and the issues that you see.

I did create another branch dando-dev-test out of it and quickly fixed it to successfully build one example. The changes that I did (3 commits):

• removed unnecessary generated files including temporary and output build files (simplifies analyses)
• removed unreferenced LPC55S69 board files (avoid confusion)
• updated LPC55S69 board layer (linker script and I2C4)

After that I was able to build the following example:
./examples/issdk/sensors/fxls8974cf/interrupt

csolution convert -s fxls8974cf_interrupt.csolution.yml -c fxls8974cf_interrupt.debug+lpcxpresso55S69_a8974
cbuild fxls8974cf_interrupt.debug+lpcxpresso55S69_a8974.cprj

There were some warnings (noncritical) and the build succeeds (no idea if it runs correctly - depending on if everything is properly configured).

Scatter file:
Only one scatter file needs to be specified in the layer yml file. The template scatter file normally come from the Startup component (DFP pack) and is then adopted to the application requirements. There can be multiple scatter file templates (Flash, RAM, Secure/Non-secure, ...). In case of ISSDK example, I took the scatter file from the application in ISSDK and copied it the correct RTE directory.

RTE directory:

RTE/<Cclass> - configuration for generic component and
RTE/<Cclass>/<device> - configuration for device specific components

For specified device LPC55S69JBD100:

RTE/Device/LPC55S69JBD100_cm33_core0
RTE/Board_Support/LPC55S69JBD100_cm33_core0

LPC55S69 DFP includes device specific drivers and should not require the CMSIS DrIver:<>:custom.
This is a bug in the DFP. I will send you an email with more information.
You can ignore the csolution convert warning about those missing components (the generated .cprj is still OK) or you can add them to the board layer (no other effect than fulfilling the unneeded requirements).

Undefined symbol Driver_I2C4 (referred from fxls8974cf_interrupt.o)
The I2C4 driver seems to be required by the application but is not enabled in the driver configuration file.

I have enabled the I2C4 driver in ./boards/lpcxpresso55s69/RTE/Device/LPC55S69JBD100_cm33_core0/RTE_Device:
#define RTE_I2C4 1

I don't know if anything else needs to be configured for the I2C4 to operate correclty. It is however enough for the build to succussed.