Hi everyone, I've been writing an async loader routine for nrf51822 to replace the current word-oriented flash write routine. Performance is good, ~22KiB/sec flash write with my STLINK-V2 compared to ~4KiB/sec currently.
The routine is based on contrib/loader/stm32f1.S. It's simple, as the flash controller for nrf51 is simple. However there's an intermittent random data corruption bug that I can't seem to track down. Every now and again, at random intervals, a 16-48 byte block of the wrong data is copied to flash by the loader routine. The data written to flash seems to be "old", ie the data is what would have been at those offsets in RAM during the previous pass of the loader through the ringbuffer. Which makes it look like a race condition somewhere, I just can't find it! I've upload the patches I'm using here: http://projectgus.com/files/nrf_async/ Also uploaded are a debug log (random.log) of flashing a random 200KiB file (random.bin), and the subsequent readback result from a dump_image (readback.bin). Can anyone with some Cortex-M0, NRF or async_loader experience shed any light? Things that help: * Adding an active_sleep(5) to the top of the while loop in target_run_flash_async_algorithm target.c:898 cures the problem completely. * Smaller buffer sizes have less corruption (I average 1-2 corrupt regions writing 200KiB with buffer size 256 bytes, ~6-8 with buffer size 8192 bytes.) Thing that don't help: * Reading back each chunk of buffer RAM immediately after it's written out confirms that the RAM is being successfully written by the debugger. * Adding a check for NVMC.READY to the loader routine doesn't change anything. (This shouldn't be necessary as the datasheet says that the CPU is blocked during flash writes, but I checked anyhow.) * There doesn't seem to be any reliable correlation between the kind of write, or whether the corruption occurs with data that is written at the beginning or the end of a chunk, or at a particular position in the buffer. Things that are weird: * So far the corrupt data chunks always seem to start aligned to 0x4 or 0xc, never 0x0,0x8. I figure this is either a really simple bug in the loader routine that I haven't spotted, or some kind of subtle interaction with the debugger or the NRF51822... I'm getting so desperate I'm even scouring the ARM literature for possible write ordering/cache writeback issues (which I know shouldn't possibly be a problem here!) Anyone have any ideas? Happy to explain any particular point at length if required, or test any theory. This has me pulling my hair out!! - Angus ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
