LPC4337 IAP erase flash hang

[definium]

Hi there, I am having a problem with IAP rom code hanging on the LPC4337.

I have a bootloader in flash bank A and application code in flash bank B.

I can erase bank B, read the app code from the SD card and program the flash just fine under the debugger. However if I run the board without debugging it hangs. When I attach to the running code I find that the MCU stuck in a loop reading the FMSTAT register at 0x4000dfe0. I appears the loop is waiting for the SIG_DONE bit to be set and this never happens. See assembly code below.

After checking for the obvious things like interrupts being enabled etc. I reverted to the LPC4337 LPCOpen example code, periph_flashiap, just to remove any variables that may be introduced by my own code.

I get the same result. I appears to be during the sector erase IAP call. The sector(s) are prepared for write/erase but the erase call never returns unless I run the code under the debugger.

The LPCOpen example uses the last sector in bank A whereas I am using bank B so the FMSTAT for bank A is being checked.

Here is the relevant bit of assembly code:

r0 = 0x4000d000 or 0x4000c000 depending in flash bank being used

r5 = 0x00000fe0 offset to FMSTAT register

r1 contains 0x00000008 after reading the FMSTAT register.

104019da:   b.n     0x104019c8
104019dc:   adds    r1, r5, #1
104019de:   beq.n   0x104019d6
104019e0:   ldr     r1, [r0, r5]      <-- Looping here
104019e2:   lsls    r1, r1, #29
104019e4:   beq.n   0x104019e0
104019e6:   pop     {r4, r5, pc}
104019e8:   push    {r0, r1, r2, r3, r4, r5, r6, r7, lr}
104019ea:   sub     sp, #12

A further problem that I have noticed with the example code is that the Chip_FMC_ComputeSignatureBlocks() call generates a hard fault. Specifically, the fault happens when writing to the FMSTATCLR register in fmc_18xx_43xx.h, although it is flagged as imprecise to I can't be too sure.

STATIC INLINE void Chip_FMC_ComputeSignature(uint8_t bank, uint32_t start, uint32_t stop)
{
    LPC_FMC[bank]->FMSSTART = (start >> 4);
    LPC_FMC[bank]->FMSTATCLR = FMC_FLASHSIG_STAT;     <-- Hard fault here
    LPC_FMC[bank]->FMSSTOP = (stop >> 4) | FMC_FLASHSIG_BUSY;
}

I am not using this feature yet but this is unmodified example code and I figure it should work.

As soon as I hit this hard fault lpcxpresso completely freezes and has to be killed externally.

I am using version 8.2.0 of lpcxpresso with the latest GDB as I know there are problems with the version supplied with 8.2.0.

Any help on these issue would be greatly appreciated.

Regards,

Mike

[svenb_]

I have exactly the same issue, hang in these 3 instructions. I tried:

 - lowering the CPU clock to 20 MHz

 - not using the top 64 Byte of SRAM

 - using bigger alignments and different page sizes

 -disabling interrupts

Nothing helped, always the same behaviour. Any tips?

[svenb_]

Ok, for me this issue was solved by a) setting the correct CPU clock in the IAP requests and esp. b) calling the IAP_INIT function (decimal code 49) beforehand.

[stype]

Sven, thank you for the update.

Before you solved the problem, did all of your chips stalled or only some of them.

I am asking since I didn't had a wrong CPU clock and I was calling the IAP_INIT beforehand. It works in almost all chips but some of them gets stalled for apparently no reason.

S.

[stype]

Hi there,

I have exactly the same issue but it does not happen on every chip, it only happens on 2 chips out of 8 chips I programmed. That's right, exactly the same code hangs in some chips and works well in the others.

Just as Mike reported, during debug it works fine, while it hangs if its not under debug mode. Reading your post Mike, it is unclear to me if you managed to resolve the bug which caused stalling in the IAP erase sector function, or you have only fixed a bug in the example Chip_FMC_ComputeSignatureBlocks() function?

I did the modification of double pointer to a single one and changed functions to dot notations, but it had no influence on stalling issue. That's logical to me as I would assume that IAP functions are in ROM address range (even our looping/hanging address 0x104019e0 is in ROM address range), and the ROM function itself shouldn't be influenced by a change in example function code.

Please let me know:

1) Did you resolved IAP eeprom erase sector hang issue?

2) If yes, what was the reason why it was happening?

3) If no, should I just assume I am dealing with a few faulty chips?

PS. My code optimization is level 0 - no optimization.

Stjepan

[brendonslade]

Thanks for reporting this - it should be fixed in the recent release of LPCOpen; the LPC_FMC pointer definition was removed from chip_43xx.h.   It is now done inside the Chip_FMC_ComputeSignatureBlocks routine.

[definium]

Found the problem with the Chip_FMC_ComputeSignatureBlocks() function.

LPC_FMC is being declared as a pointer to a pointer but it is not. It is a pointer to a struct.

#define LPC_FMCA ((LPC_FMC_T *) LPC_FMCA_BASE)
#define LPC_FMC ((LPC_FMC_T * *) LPC_FMCA_BASE) 
#define LPC_FMCB ((LPC_FMC_T *) LPC_FMCB_BASE)

So the following line ends up trying to write the value (start >> 4) to a location pointed to by the contents of the FMSSTART register and that ends in tears.

LPC_FMC[bank]->FMSSTART = (start >> 4);

I change the LPC_FMC declaration to the following in chip_lpc43xx.h:

#define LPC_FMC ((LPC_FMC_T *) LPC_FMCA_BASE) 

and then changed all the register references in fmc_18xx_43xx.h to dot notation, i.e.

LPC_FMC[bank].FMSSTART = (start >> 4);

I wanted to attach the modified files but I just could find how to do it while posting this time.

Mike