Not too happy with NXP!

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Not too happy with NXP!

749 Views
BillTheBiker
Contributor III

So we get the LPC54628 with some really impressive specs.  What NXP fails to tell the user are the following *minor* details:

  1. To relocate code into spiffy,the user has to use a macro in front of each function (or prototype).  Couldn't NXP have made this based on a module or library, so I do not have to claw my way through the map file to see what is placed locally and re-locate the function using __TEXT(Flash2) macro??
  2. One of the attractions of the NXP was the rom-based USB MSD stack.  So the chip shows up as a drive and drop in the image and boom, off to the races.  The only problem is the build-in ISP does not recognize the spiffy flash so the most you can load into the 512K segment is a bootloader which has to write to the target addresses.  Which brings me to point 3
  3. So NXP provide binary utilities for extracting INTEL .hex information from the .asf file.  This stops at 16-bits!  So there are no 0x04 records for extended addressing.  If you create a .bin file it is on the order of 256Mbytes!  This is because the utility regards the LPC as linear address space and does not offset to the 0x1000000 where spiffy is located
  4. MCUXpresso as far as I am concerned is devil's spawn.  Admittedly we have a large application, but the tool will get confused to the point where the only option is to delete the workspace and reload from the repo.  It seems to be very fussy about include orders and library includes orders.  I love Eclipse but the stuff NXP glommed on top of Eclipse is simply awful

There I feel much better now!

0 Kudos
2 Replies

527 Views
lpcxpresso_supp
NXP Employee
NXP Employee

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

527 Views
BillTheBiker
Contributor III

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

0 Kudos