No System Reset issued prior to flash programming. #74
Comments
|
I'm having a similar problem with flashing images on my STM32F4 Discovery, but I'm having some trouble finding a pattern. Uploads complete and are verified, but sometimes the loaded program crashes. Pressing reset sometimes works to restart the program -- but sometimes doesn't. Even power cycling the board doesn't make it run properly. What does work is disconnecting and reconnecting the USB cable and then uploading the same image. This produces a stable running program. Further uploads of the same image with the cable still connected still produce a running program! Meanwhile, changing the program slightly in size (or just moving things around in the code harmlessly) and uploading sometimes provokes crashiness. My only work around is to reconnect USB before transfer to ensure a good load. The program I'm using is a modified version of the FreeRTOS demo program that uses PWM to fade up the LEDs in response to forces on the MEMS accelerometer on-board. In addition, I'm using USART3 to drive an ADM1602U serial-enabled LCD. I can't imagine that bringing up the USART is producing the bad loads, because after reconnecting USB, the USART is up (and idle), but the loaded program certainly runs. When the board is up and running happily and a transfer is initiated, attached hardware (including LEDS attached to GPIO pins) stay lit in whatever condition they were in, which doesn't seem consistent with a proper, full reset where the GPIO pins would be floating and thus unable to deliver current. This might occur if a shorter (<10 microsecond) partial reset is being used instead. |
ghost
mentioned this issue
Commit 0ed399 added the clearing of DMA registers that was preventing programming (see issue stlink-org#74), however it uses hardcoded addresses of the DMA registers on the STM32F4. This seems to prevent the flashing and verification on STM32L1, as the registers only partly cover the range zeroed. So the DMA clearing has been limited to the STM32F4 microcontroller. Additionally, sometimes, typically directly after erases, a 'flash loader run error' will occur that terminates the writing. This is not necessary, as the writing is successfully performed by page writing (line 1581 onwards of stlink-common.c), and so has been returned to a error message (see issue stlink-org#112). There is a comment on line 1574 (added by Uwe Bonnes in commit 0164043) that this may happen on blank devices, and so the fatal error message is the incorrect response.
Commit 0ed3907 added the clearing of DMA registers that was preventing programming (see issue stlink-org#74), however it uses hardcoded addresses of the DMA registers on the STM32F4. This seems to prevent the flashing and verification on STM32L1, as the registers only partly cover the range zeroed. So the DMA clearing has been limited to the STM32F4 microcontroller. Additionally, sometimes, typically directly after erases, a 'flash loader run error' will occur that terminates the writing. This is not necessary, as the writing is successfully performed by page writing (line 1581 onwards of stlink-common.c), and so has been returned to a error message (see issue stlink-org#112). There is a comment on line 1574 (added by Uwe Bonnes in commit 0164043) that this may happen on blank devices, and so the fatal error message is the incorrect response.
|
Should be fixed on latest master. Please reopen this issue, or open a new one. |
Nightwalker-87
added
code/feature-request
os/linux
status/resolved
target/stm32f4
and removed
needs/investigation
code/feature-request
labels
Using either GDB server or the 'flash' utility and an STM32F4 Discovery board under Fedora 13 Linux to program an STM32F105RBT6 target processor. The target embedded application uses DMA to continuously load ADC values into SRAM. It appears that during flash programming the DMA peripheral continues to run, overwriting the flash data as it is loaded into SRAM, corrupting a block of 16 bytes in every flash page written and resulting in verification failures.
Attempts to modify the stlink_fwrite_flash() function in src/stlink-common.c to call stlink_reset() and stlink_force_debug(), or to hit the SYSRESETREQ bit in the SBC_AIRCR of the target in an effort to stop the DMA prior to flashing were unsuccessful.
A workaround is to flash twice - first with a binary that is smaller than the location of the corrupted 16-byte block which does not use DMA, then subsequently with the desired target code.
The text was updated successfully, but these errors were encountered: