So we get the LPC54628 with some really impressive specs. What NXP fails to tell the user are the following *minor* details:
There I feel much better now!
I'm sorry to hear about your issues. A few comments which I hope will help ....
1. Making use of the SPIFI Flash in addition to built-in flash
There are actually several approaches to doing this. The section macros that you reference are really intended for just placing small number of functions (or data items) into "non-default" locations.
If you have a large amount that you want to locate into external flash, then I suggest you take a look at section 17.15.2, "Configuring projects to span multiple Flash Devices" in the MCUXpresso IDE v11.1.0 User Guide, which provides an alternative method. You could also make use of the "Extra linker script input sections", as described in section 17.13.1 "Placing code and data into different Memory Regions".
2. Ability to program SPIFI Flash from ISP
I believe this is a restriction of the bootrom, but really out of my scope to comment
3. Hex conversion
The utilities for converting the generated image to srec or hex format are provided by the standard GCC binutils package.
In relation to your issue with hex conversion, can you provide more details?
In relation to binary conversion, yes, this is standard, as a binary has no address information inside it - so gaps in the memory map have to be padded out. There are various ways of avoiding this though. For instance, you can run objcopy twice, once for each flash section - using commands along the lines of :
arm-none-eabi-objcopy --only-section .text_Flash2 -O elf32-littlearm "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}_EXTFLASH.axf" arm-none-eabi-objcopy --remove-section .text_Flash2 -O elf32-littlearm "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.axf"
Of course, another option for programming the image is to do this directly from the IDE via your debug probe (which requires no image conversion to be done). This will be done when you start a debug session from within the IDE, or you can use the built-in tool directly without debugging. For more details on the later, please see chapter 14, "The GUI Flash Tool" in the MCUXpresso IDE v11.1.0 User Guide.
4. MCUXpresso IDE Reliability
If you would like to post a more details description of your complaints (preferably into the MCUXpresso IDE community : MCUXpresso IDE) , including IDE version, SDK version, and what problems you see and in what circumstances, then we would be more than happy to try and help you to resolve your issues.
Regards,
MCUXpresso IDE Support
Not sure what details you need. We take the .asf and run the utility and end up with either a binary which is huge, or the .hex file limited to 16-bit addressing. We can pad the binary, so it is not the end of the world. The link to the spiffy flash was really useful; I wrote a ticket to support about this and no-one mentioned this option as it solves my problem. The IDE issues have calmed down for sure, the main one was constructing a solution of multiple projects where there are inter-dependencies to the projects. The order you reference the projects is critical and caused many confusing linker errors; we do get situations where the downloaded image seems corrupted and will not run. The source is not changed but the working image is no longer working. A clean and rebuild fixes the problem, but it has caused me on two occasions to back out a bunch of work thinking I introduced a bug. Now I clean and build more regularly to make sure this condition does not occur. All good, thanks for the reply it was very helpful