System Bootloader not working but UART1 works OK.

[bob239955]

Posted on January 15, 2009 at 14:22

System Bootloader not working but UART1 works OK.

[bob239955]

Posted on May 17, 2011 at 12:19

Uart1 works fine with my application to my PC COM1 port but when I change the boot0,1 pins and boot from system boot memory to talk to the 'flash loader demonstrator' it says 'Cannot start BL.. please restart device and try again.' I reset by pulsing NRST low manually and try again but see same message.

The BL vector table and code seems to be present in the STM32f103rbt6 revision B memory at 0x1ffff000. Do I need to ensure any other pins are held high or low at this time? e.g. UART1 CTS,RTS? JTAG? The hardware platform is a STM32 Primer with mods for UART1 connection, boot0/1 links, reset button. Any help would be great - thanks. [ This message was edited by: bobz on 07-12-2007 16:45 ]

[16-32micros]

Posted on May 17, 2011 at 12:19

Hi Bobz,

Could you please make a dump of your whole memory at 0 and at 0x1FFF F000 with a length of 2Kbytes only using your debugger either in raw binary file , Intel or Motorola Format and send me back thru the forum , so I can check/debug it and let you know. Could also provide me the whole Date Code written in the Package this is very useful for tracking. Thx. STOne-32 [ This message was edited by: STOne-32 on 07-12-2007 21:12 ]

[16-32micros]

Posted on May 17, 2011 at 12:19

Dear Bobs,

Could you please check your USART1 RX and TX Pins, the bootloader is using only PA9 as TX and PA10 as RX and not PB6 and PB7. Let me know if you have some news :) STOne-32

[bob239955]

Posted on May 17, 2011 at 12:19

Hi ST-One

Thankyou for your help. Please find attached a memory dump of 0x1ffff000 and 0. I presume that memory address 0 should look the same as at 0x1ffff000 but it doesn't. I cannot be 100% sure the debugger tool has updated the memory views since reset which may explain why 0x00000000 and 0x1ffff000 differ. PA9 and PA10 are being used for UART1 Tx and Rx (no alternate pin mapping). Also I re-checked Boot0 and Boot1. Boot0 is held high by 100k (to Vcc3 = VDD1,2,3,4,A). Boot1 is connected direct to Ground (=0V =Vss1,2,3,4,A). Reset is generated by manually applying 0V directly to pin 7 NRST. Pin7 NRST is also connected by a 100nF to 0V and a 100K to VCC3. Pin7 NRST is also connected via 120 Ohms to an alternate reset source which is high (not in reset state). The debugger tool is Ride7.00.0002 (rkitARM 1.01.0002) Marking on the chip reads; ARM B STM32F103 RBT6 22DGS 93 (the D could be a 0,the S could be a 5) MLT22 738 Once again many thanks for your help. Bobz [ This message was edited by: bobz on 10-12-2007 13:11 ]

[16-32micros]

Posted on May 17, 2011 at 12:19

It seems that the file is not attached.

[bob239955]

Posted on May 17, 2011 at 12:19

It may be now.

[16-32micros]

Posted on May 17, 2011 at 12:19

Hi Bobz,

The file/dump memory is right and containing the v2.0 bootlaoder. What I suspect now is your hardware inizialization phase, because when booting from system Memory you should have address space at 0x is the same as at 0x1ffff000. Is it possible to change the 100K to 10K and try the sequence again. You need also a transeiver for RS232 to your PC if it is not yet done. Thx. STOne-32

[bob239955]

Posted on May 17, 2011 at 12:19

Thanks ST-One-32 that is helpful.

Assuming you meant the 100k on the Boot0 line to Vcc3, I will change that to 10K and let you know if that is a fix. The tranceiver is already OK because UART works fine to a PC comm port when my application is loaded. Thanks again.

[bob239955]

Posted on May 17, 2011 at 12:19

Regretably the 10K did not fix the problem.

Note a) the STM32 OSC_IN/PDO frequency is 12MHz. b) the STM32 Jtag TRST is high c) Flash loader demonstrator version is 1.0. d) Flash Loader demonstrater settings were COM1 9600 baud 8 data bits no parity 1 stop bit, 10s timeout. but also tried default 115200 baud, and 5 s timeout. e) My RS232 Tranceiver is powered from the RS232 port from DTR. Observations regarding boot0(pin60), boot1(pin28) on 64pin package. 1. changing boot0/boot1 from 0/1 (flash) to 1/0 (sys boot) DOES correctly stop the STM32 booting from flash when it is reset because the flash application does not start. 2. Therefore it seems the debugger falsely shows the ram at 0 to be the same as the flash application after resetting in system boot mode since if it really was the same the application would run. 3. restoring boot0/boot1 to 0/1 to boot from flash boot from flash application as expected - since the application works again. 4. I monitored the output from the 'Flash loader demonstrator' and it is 0x7F. 5. I monitored the response output from the STM32 on USART1 and at 9600 baud its any of these single bytes 0xFF, 0xEF, 0xDE, 0xEF, 0x00, 0xFF and it is emitted emmediately after the STM32 is reset. 6. I followed the instructions by FIRST resetting the STM32 THEN clicking next button on the 'Flash loader demonstrator 1.0'. As instructed. These tests were done without the debugger. Any Ideas?