LPC1769 Issues

[gdbnoobie]

3 questions.

1. The LPC1769 has 512k program flash, but the LPC1769_flash.lds says  it’s 256K. Is that something that should be fixed?
2. When I program from the device inside Visual Studio, it works. When I go to program the same target with the hex file using Segger J-Flash, it warns me that the checksum is not correct (see image) and it changes these 4 bytes (set to 00) with a proper checksum. How can I get the checksum programmed properly in Visual Studio and put into the hex file, without using J-Flash to fix it?
3. In Visual Studio, when I select ‘Program and Start without Debugging’, I get a “Debugging Failed” message, exception details:

 

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> tq1+x1: Failed to program 1 out of 5 sections
at VisualGDB.Common_GUI.WPF.ItemizedProgressWindow.RunAction[_ResultType](cz1`1 action, String title, String caption, zn exceptionHandler, Int32 noFormTimeout, String[] stages)
at m02.d.m1`1.f()
at p72.y`1.c()
--- End of inner exception stack trace ---
at p72.e2[_Type](v2`1 a)
at m02.d.k_2[_ResultType](cz1`1 d, String b, Int32 c, String[] a)
at m02.LaunchGDBProjectWithoutDebugging.ExecuteForProject(m02 instance, Project prj)
Thanks.

• This topic was modified 6 years ago by gdbnoobie. Reason: formatting
• This topic was modified 6 years ago by gdbnoobie. Reason: formatting
• This topic was modified 6 years ago by gdbnoobie.
• This topic was modified 6 years ago by support. Reason: formatting

Attachments:

You must be logged in to view attached files.

[support]

Hi,

We have rechecked the LPC1769 memory map and it indeed looks like a bug. The memory size definitions for the legacy NXP devices were taken from the NXP’s product lists and most likely there was an error there at the time when our BSP was generated. As a workaround, please consider creating a copy of the LPC1769_flash.lds file in the project directory (via VisualGDB Project Properties) and patching it in place.

Generally, for NXP devices we would advise using newer device families that are using the MCUXpresso framework (e.g. see this tutorial) so that VisualGDB will automatically import the correct linker scripts, device definitions and examples. The older LPCOpen-based SDKs have considerably lower quality and are no longer maintained, so VisualGDB could have picked up some incorrect definitions from them.

The checksum is specific to certain NXP device families and is indeed not automatically computed by VisualGDB. If you are using VisualGDB with Segger J-Link, it might provide a special command for updating the checksum on-the-fly (please double-check if with Segger support if you are not sure). For stand-alone programming scenarios, NXP recommends doing it manually, sorry. We can help you understand the VisualGDB-driven build process and the underlying tools that could be used to inject the checksum, however unfortunately we will not be adding out-of-the-box support for it as it only affects a small subset of no-longer-maintained devices.

The programming error can be normally diagnosed by clicking the “view details” button or link (depending on the way the message is shown) or via View->Other Windows->VisualGDB Diagnostics Console. It is likely generated by the underlying tool (e.g. Segger J-Link) and examining the tool log should point to the root cause.

[Author]

Posts