Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

No System Reset issued prior to flash programming. #74

Open
emeb opened this Issue · 1 comment

2 participants

@emeb

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.

@patrickmjordan

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.

@sheaff sheaff referenced this issue from a commit in sheaff/stlink
A Sheaff Clears DMA config registers for Discovery F4 board
to allow flash programming.  See texane/stlink issue #74.
0ed3907
@6thimage 6thimage referenced this issue from a commit in 6thimage/stlink
@6thimage 6thimage Limited DMA clearing to STM32F4, removed fatal error for flash loading.
Commit 0ed399 added the clearing of DMA registers that was preventing
programming (see issue #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 #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.
9d5710b
@6thimage 6thimage referenced this issue from a commit in 6thimage/stlink
@6thimage 6thimage Limited DMA clearing to STM32F4, removed fatal error for flash loading.
Commit 0ed3907 added the clearing of DMA registers that was preventing
programming (see issue #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 #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.
0b2c105
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.