Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Werner

Pages: [1]
LPC2xxx / Re: FlashMagic 12.75 doesn't erase/program LPC2129
« on: January 29, 2020, 06:28:12 am »
Ok, I found the oscilator frequency field has moved to View->Preferences->Hardware.
Unfortunately the import of an old .fms file doesn't fill this field.

LPC2xxx / FlashMagic 12.75 doesn't erase/program LPC2129
« on: January 29, 2020, 05:24:47 am »

i found that FlashMagic 12.75 cannot erase/program an LPC2129 anymore. Reading device signature works well.

I took a terminal program in order to watch for differences between FlashMagic 11.20 (erase/program works well) and FlashMagic 12.75 and found that FlashMagic 12.75 sends an oscillator frequency of 0. With that the erase command stalls inside the LPC2129.

FlashMagic 11.20 has a field for an adjustble oscillator frequency which is filled with 12.000 MHz by default. The LPC2129 has no internal RC-oscillator but always runs on the external crystal. So the LPC2129 needs this number for the erase/program timing.
I tried to set the oscillator frequency to 0 in FlashMagic 11.20. Then the LPC2129 stalls again. Setting a frequency of 100 MHz makes erasing very slow.

FlashMagic 11.20 LPC2129 Erase all command, sent:
?Synchronized<\r><\n>12000<\r><\n>J<\r><\n>U 23130<\r><\n>P 0 16<\r><\n>E 0 16<\r><\n>

FlashMagic 12.75 LPC2129 Erase all command, sent:
?Synchronized<\r><\n>0<\r><\n>J<\r><\n>U 23130<\r><\n>P 0 16<\r><\n>E 0 16<\r><\n>


When I start FlashMagic by double-clicking an .fmx-file a message comes up ("The project has been modified. Do you want to save it?"). I have to click "No", then the settings of the double-clicked .fmx-file are loaded. Is this the wanted behavior of FlashMagic? Older versions of FlashMagic worked well by double-clicking the old .fms-file.

Best regards

ARM Cortex / Nice to have
« on: December 09, 2014, 05:02:30 am »
Hi Andy,

for the LPC1853 and other devices one can choose whether to access flash bank A or B. FlashMagic is able to take just the relevant parts of the hex file for programming.
It would be nice to have a third option "All" in order to program the entire flash in one step.

ARM Cortex / Re: LPC1853 Can't Access Flash Bank B at 0x1B000000
« on: December 08, 2014, 05:27:20 am »
Hi Andy,

V8.61 solves the problem. What a quick response!

Best regards

ARM Cortex / LPC1853 Can't Access Flash Bank B at 0x1B000000
« on: December 05, 2014, 01:24:33 pm »
when I try to program (or even blank check) Flash bank B on my LPC1853 (Rev '-'), I get an error message: "Device does not support operation (no flash memory)". But the LPC1853 does have 256kB Flash on Bank B.

The Display Memory command does work on bank B, of course it shows an empty memory, since I haven't been able to program it yet.

LPC9xx/LPC9xxx / Re: help me for isp on lpc936
« on: April 28, 2009, 08:32:50 am »
I do not understand much of your program, but it looks like you want to send ISP commands with another microcontroller.

You must not send
because these records are outside the 16k code region of the LPC936.

FlashMagic translates this part of the hex file (0xFFF0...0xFFFF) into misc-write-commands for UCFG1, Security Bytes, etc.


LPC9xx/LPC9xxx / Re: LPC9xx baud rate tolerance
« on: November 12, 2008, 02:32:15 am »
Hi Andy,

the first LPC935 i grabbed had -1.5% with clean 3.2V at room temperature. This may still comply with the specification (+/-2.5% over full temp, nothing else).
But this deviation of -1.5% is already too slow for the ICP bridge to perform programming (every other command works).

The problem is not the baud rate deviation itself. Serial communication normally works with a baud rate mismatch of 3% and this is also true for the LPCs. The problem is the missing buffer memory and the long data records that have to be echoed in time. A full-length (64 bytes) program record contains 137 bytes and these are used in FlashMagic. But even with -1% after 100 bytes the "one-byte buffer SBUF" has reached the end.
Positive deviations are no problem at all because then the echo is sent faster than the next byte comes in.
I think there are two possible solutions:

1. In FlashMagic:
Time gaps in transmission after 32 bytes.

2. In the ICP-bridge:
Enabling UART double buffering mode (halfes the deviation problem),
Using an accurate autobaud measurement (reduces the deviation itself).

I sucsessfully tried the second solution. Unfortunately the ICP-bridge code is available as a hex-file only. I had to disassemble the ICP-bridge code to insert my autobaud/double buffer routine. So it's a job for NXP to do.

Basically the ISP-bootloader suffers from the same problem. But due to a rounding bug in the bootloader autobaud function the detected baud rate tends to be a little faster. (In fact this is the reason why communication only works with baudrates up to 7200 baud.) So nobody has experienced the deviation problem with the ISP-bootloader yet. But with high speed communication the deviation problem shows up again.

so, long

Hi Erik,

have you got the source code of the ICP-bridge software? Tell me where to get it. I'm looking for it for so long.
Then i would be able to write to TRIM or BRGR0 and 1.

Hi Kittmaster,

i discovered the same problem while working on the bootloader program.
The problem is that your chip in the ICP-bridge has an rc-oscillator with frequency of a little less than 7.3728MHz. Because the bootloader or the ICP-bridge has to echo every received byte, long records (used for programming) overflows the receiver at some time.

As long as the problem isn't fixed by software the only thing you can do is to try a number of chips in the ICP-bridge until you find one with a little faster oscillator. Then echoing is faster than receiving and your programming works.

Good luck

LPC9xx/LPC9xxx / LPC9xx baud rate tolerance
« on: November 07, 2008, 11:16:28 am »
Hallo Andy,

i found a problem in flashmagic (Version V4.33.1397):
During programming flashmagic sends records of 64 bytes data plus some more for address, checksum etc. All bytes are sent with maximum speed without any gaps between them (just 1 stop bit).
The ISP bootloader resides in the top region of the flash and therfore cannot use RX/TX interrupts in conjunction with RAM buffers. Since the chip has to echo every received byte the bootloader can receive bytes only as fast as its transmissions are. If the chip's baud rate is slightly slower than flashmagic's baud rate and there are many bytes to receive (and to send back), at some time flashmagic overflows the bootloader and one byte is lost. Them programming stucks and a transmit/receive error occours. This also occous with the ICP-bridge at 19200 baud.

The tolerance of the LPC9xx RC-oscillator has become worse. In the beginning almost every LPC932 had +/-1%, now there are many LPCs with +/-2.5%

So now my question:
Is it possible to insert a time gap of 1 byte every 16 or 32 bytes? Then the chip would be able to catch up timing.

I've got a second question:
I modified the bootloader to autobaud up to 115200 baud. Who is the right person at NXP to make a suggestion?

Kind regards

Pages: [1]