2017-09-05 01:13 AM
Hello,
by chance I got hold of a NUCLEO-H753ZI board. Using STLINK V2J28M18, I can read memory and flash as expected. But reading system memory at 0x1ff00000 gives 'Device Memory not accessible'. As another indications, I can't get any of the bootloaders to react, e.g. dfu by shorting CN1 Pins 5 and 7 and connecting a USB to CN13.
I don't see anything bootloader related in the errata sheet ES0392 Ver. 1. Do I do anything wrong, is my single chip broken or is there a problem with bootloader on STM32H743 Rev. Y?
2017-09-07 02:38 AM
Hi
Bonnes.Uwe
,Since you are referring to STM32H743 rev. Y, I think you are working with a
http://www.st.com/en/evaluation-tools/nucleo-h743zi.html
(and not a NUCLEO-H753ZI). Can you confirm ?So I tried to reproduce your issue on a NUCLEO-H743ZI, and on my side I was able to activate system bootloader and DFU mode.
As you described, in
http://www.st.com/resource/en/application_note/cd001675pdf
STM32 microcontroller system memory boot modesection 1 p. 188, pattern 10 should be applied to activate bootloader: i.e. from Table 2 p. 21, either Boot(pin) = 0 and BOOT_ADD0(optionbyte) = 0x1FF0 or Boot(pin) = 1 and BOOT_ADD1(optionbyte) = 0x1FF0.As you did, I took the second pattern 10 configuration, and short-circuited pin VDD and BT0 on CN11 connector (pin 5 and 7 of ST morpho connector, see Table 21 in
http://www.st.com/resource/en/user_manual/dm002445pdf
).Also, I have previously installed on my PC under Win7 pro x64, the tool
http://www.st.com/en/development-tools/stsw-stm32html
v3.0.5, since it contains also the DFU driver (STTube) needed.Firstly, I connected the Nucleo board through ST-Link, powered it up (LED LD4 is red, not blinking).
Using
http://www.st.com/en/development-tools/stsw-linkhtml
, I connected to the board (LD4 blinking red/green) and updated option bytes with the following configuration:On my board,ST-LINK Firmware version : V2J28M18
Once done, I disconnect from the board (LD4 is red not blinking)
Secondly, I connected the USB cable through CN13 to my PC.After a reset of the board, the device is then recognized as an STM device in DFU mode (I needed still a few trials - USB plug/unplug - at first for going out of an unknown USB device state).
In the Windows device manager, under USB controllers, it appears like this:
When launching DduSeDemo windows application, I got the confirmation to talk to the system bootloader which is in DFU mode (see available DFU devices on top):
Could verify these steps on your side ?
I have also seen previously difficulties to install STTube under Win Is this your case ?
Best regards,
Cedric
2017-09-07 10:42 AM
It is a Nucleo-H743ZI, I misstyped the number in question above. I did the checks again, and 0x1ff0000 up to 0x1ff08000 are still not readable and bootloader is not entered. CN3 does not even request enumeration (DP connected to 3.3 Volt via internal 1.5 k). As I work on linux, I check with dmesg and lsusb. I also erased the chip, with no difference/
So I think my chip is broken w.r.t the bootloader. It is a Y revision with date code 705.
2017-09-13 08:43 AM
Hi
Bonnes.Uwe
,I am also working on a NUCLEO-H743ZI with an STM32H743 rev Y (checked with STM32 ST-LINK Utility) and production date code 705 (on package).
I have the same behavior as you, when trying to access System Flash Memory on Bank 1 from address 0x1FF00000 to 0x1FF1 FFFF through STM32 ST-LINK Utility. I receive the error message Device Memory not accessible.
Still I am able to read system bootloader version (see table 3 p. 25 from
http://www.st.com/resource/en/application_note/cd001675pdf
) at address 0x1FF1E7FE, and get bootloader ID 0xD2. Do you have the same version on your side ?Also after reset of the board connected only through ST-Link, if I look at program counter (PC) location through the ST-LINK_CLI command line utility:
'C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility\ST-LINK_CLI.exe' -c hotplug -CoreReg
I get for example PC = 0x1FF0BAB0.
On successive look-ups, I see it looping in this memory region. This is for me an indication that system bootloader is in the loop described in AN2606 at Figure 48 p. On this Figure, we see also that if any activity is detected on USART, I²C or SPI, system bootloader will go out of the loop. So sometimes, we are not able to enter the USB cable detection for DFU, because we have active signals on other peripherals monitored by the system bootloader.
I am working with the original setup of the Nucleo board (jumpers and solder bridges). Did you configure it specifically on your side , or do you have other peripherals connected along with ST-Link and USB cable on CN13 ?
Today I am not aware of any specific system bootloader issues on STM32H7 If it is possible, you may try with another Nucleo board.
Best regards,
Cedric2017-09-13 11:04 AM
Date code is '705' too. Byte at 0x1ff1e7fe is 'B0'. Strange, same date code but different bootloader version. With boot=1, pc after reset is also in the region 0x1ff0bXXX. UID is 000a8012 3436510c 30333230.
There is nothing connected to the Board. I don't have another H7 nucleo, also I have other boards, but with no problems to enter or read bootloader.
2017-09-18 09:30 AM
Hi
Bonnes.Uwe
,I got confirmation that DFU is only supported on STM32H743 with system bootloader version >= 0xD2.
Unfortunately, this is not the case on your side. I am sorry, you will need to find another Nucleo board having a MCU with a more recent bootloader to test this feature.
Best regards,
Cedric
2017-09-22 04:33 AM
I got another board, this time from Farnell, Rev Y and date code 719. STlink access to 0x1ff00000 is still denied, but DFU works.