Messages

Hi all,

I found that the current version of FlashMagic (V13.50) corrupts location 0x001C on bank B if "Activate Bank A" is checked. FlashMagic erases the chosen Flash blocks, then programs bank A, then programs bank B and then sends the ISP command to activate bank A. According to the NXP user manual this ISP activation command generates and writes the correct vector table checksum on location 0x001C for bank A and at the same time writes an invalid checksum (in fact 0x00000000) on location 0x001C on bank B. Dependant on what code is located at 0x001C this leads to the program to behave falsely or even crash.
Actually this is not a fault in FlashMagic itself, rather a bug in the design of the ISP command, but FlashMagic should work around it.
I suggest Flashmagic to change the order of operation: Erase the chosen sectors on the bank to be activated, program the bank to be activated, activate the bank, erase the chosen sectors on the other bank, program the other bank.

With older versions of FlashMagic (V9.80) one has to execute FlashMagic twice. One instance set to bank A and bank activation checked, the other instance set to bank B and bank activation unchecked. This process avoids corrupting the non-activated Flash bank and has worked fine for me.
Surprisingly neither version 13.50 nor version 9.80 shows an error when the corrupted code is verified. Obviously code location 0x001C is spared for verification on both banks.

Best regards
Werner

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.

Hallo,

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>

Hi,

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
Werner

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.

Hi Andy,

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

Best regards
Werner

Hi,
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.

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
  :04FFF00023001E00CC
  :08FFF8000003020000000007F5
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.

Werner

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
Werner

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
Werner

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
Werner