stm32f102c8t6 doesn't flash about stlink HOT 8 CLOSED

I failed to find the root of the problem by the moment but I've found out the following information. I hope it is useful.

I checked the code of "st-flash" utility and found out the following. It loops forever in
stlink_erase_flash_page() -> stlink_wait_flash_busy(). when it is called here

/* start erase operation, reset by hw with bsy bit */
set_flash_cr_strt(sl);

/* wait for completion */
wait_flash_busy(sl);                 <- this line is 1070

/* relock the flash */
lock_flash(sl);

I tried adding some delay in the following way:

static void wait_flash_busy(stlink_t sl) {
/ todo: add some delays here */
while (is_flash_busy(sl))
usleep( 100000 ); <- this line.
}

but it doesn't help. read_flash_sr(sl) result is always 3 and "read_flash_sr(sl) & (1 << FLASH_SR_BSY)" is 1 respectively.

It seems previous operations in stlink_erase_flash_page() are wrong a bit:

/* unlock if locked */
unlock_flash_if(sl);

/* set the page erase bit */
set_flash_cr_per(sl);

/* select the page to erase */
write_flash_ar(sl, flashaddr);

/* start erase operation, reset by hw with bsy bit */
set_flash_cr_strt(sl);

from stlink.

Can you run in the debugger and make sure that in is_flash_busy() the F2/F4 code path is not taken. Perhaps we somehow decipher the chip_id wrong.

gdb st-flash
b is_flash_busy
r write 0x80000000
and when is_flash_busy is hit check the chip_id

Hope this helps.

from stlink.

Thank you very much for reply!

It seems to me F2/F4 path is not taken. I followed "st-flash" line by line with GDB and the path taken in function stlink_erase_flash_page(...) is the following:

else if (sl->core_id == STM32VL_CORE_ID)
{
/* wait for ongoing op to finish */
wait_flash_busy(sl);

/* unlock if locked */
unlock_flash_if(sl);

/* set the page erase bit */
set_flash_cr_per(sl);

/* select the page to erase */
write_flash_ar(sl, flashaddr);

/* start erase operation, reset by hw with bsy bit */
set_flash_cr_strt(sl);

/* wait for completion */
wait_flash_busy(sl);

/* relock the flash */
lock_flash(sl);
}

The routine loops infinitely in second from the bottom function wait_flash_busy(sl). In this function (wait_flash_busy(...)) result coming from ST-LINK is 3 and 0 bit is checked. So result is always 3 & (1 << 0) = 1. In is_flash_busy(...) second path takes place, e.i.

else
    return read_flash_sr(sl) & (1 << FLASH_SR_BSY);

I try checking if sector erase procedure corresponds documentation. I've found something related to FLASH in PM0075 "STM32F10xxx Flash memory microcontrollers". Is it a correct place to compare? I've compared FLASH erase procedure with one from PDF. It looks like they match. FLASH_KEYR, FLASH_CR, FLASH_SR, FLASH_AR and all appropriate bits also match.

from stlink.

Here I tested the stlink-v1 with the stm32-discovery. The STM32F100 RBT6 on that board is also a medium density device, but flash programming is covered by pm0063 versus pm0075 for 101/102/103/105/107. Reference manual is rm0041 versus rm0008. I also programmed STM32F105RC with a standalone STLINK. But this is a connectivity line part. So check for subtile difference in medium size F100 and medium size F102 programming.

B.t.w: Perhaps cabling has some influence. Is it short and sensible? Do you have access to a standalone STLINK to compare?

from stlink.

I've compared pm0063 with pm0075. It looks like procedures are the same. Registers and bits involved are the same as well.

As for cable, at the moment it is about 9 cm long. I may play with it and I think I may make it as short as about 2 cm. The strange issue is that is is flashed very well with Atollic GDB server from one hand. And from the other hand FLASH content remains completely unchanged after erase attempt either with "st-flash" or "st-util"-"arm-none-eabi-gdb" couple.

Unfortunately, I don't have ST-LINK with stm32Fxxx, only with stm32Lxxx. With it I experience no problems. But flashing procedures are different in this case.

Anyway, I'll try very short cable and report about results.

from stlink.

9 cm is really short ;-)

I don't think making the cableeven shorter will help. And I compared pm0063 with pm0075 too and found no difference too. Do you have access to a scope or logic analyser?

Other idea: Does Atollic perhaps set some option bit? Erase the device with Attollic and try to program, erase and program with st-flash. If that works, try to find the offending option bit and make st-flash emit some warning.

from stlink.

Hello!

I'm very surprised but today board's managed to be flashed by st-flash. What's changed? I've soldered nokia 3310 screen to it :)

The situation is the following. With Atollic GDB server it still flashes with 100% probability. With st-flash from here https://github.com/texane/stlink sometimes it doesn't. Success probability is about 60-70%.

I've added a few improvements (at least I think these are improvements) to flashing routines such as maximum wait time, return in the case of failures at a step with a result where it concerns flash erase and fixed function name in log message. I've no idea why, but flashing probability with it is also 100%. It might be because of optimization off and additional usleep()s between USB queries related to flash busy checks.

Anyway, if my modifications look usefull it might be it would nice to merge them. The branch I've created is the following: [email protected]:z80/stlink.git.

from stlink.

Problem has been solved.
No patch necessary as modification is user-specific and has therefore not been submitted.

from stlink.