2018-02-14 01:21 AM
Hi,
We have already designed and fabricated the PCB in our project using STM32L452xx as our application processor.
We have used PA9 as USART1_Tx and PB7 as USART1_Rx pins, later when we were unable to download our code using boot loader, we learnt that we should have used PA9 and PA10 as USART_Tx and USART1_Rx, now its not possible to change the pin from PB7 to PA10. So what is the feasible solution. Can we rewrite Boot loader code by configuring PB7 and PA9 and flash the code using ST-link2 ? Or is there any other alternative solution ?
2018-02-14 02:20 AM
Hello,
Factory bootloader is stored in the internal boot ROM memory (system memory) of STM32 devices. It is programmed by ST during production and there is no option to change it (edit, overwrite etc.) afterwards. This applies also to pins assigned to USART interfaces. It is specified in
http://www.st.com/resource/en/application_note/cd00167594.pdf
. For STM32L45xx you can refer to table 106:USART1: PA9, PA10
USART2: PA2, PA3USART3: PC10, PC11If you would like to use other pins for USART bootloader, then you may consider developing your own bootloader.
Regards
Szymon2018-02-14 07:10 AM
You can write your own IAP (In App Programing) solution, it will needed to be programmed into the FLASH, and your app code will need to be placed deeper into the memory.
Probably cheaper to spin the PCB than get ST to change their design, which is documented.
2018-02-22 09:53 PM
Hi Clive,
As suggested by you, we have built IAP code, downloaded from STM portal, as per their app note we have to use ymodem protocol to send binary file. Now if I try to download my binary using Teraterm, but IAP is receiving only <SOH>=01 and <Block>=00, but no data bytes after wards, perhaps FTP app from Teraterm is expecting ACK ?. As per my understanding it should expect an ACK/NACK only after sending 132 bytes(128 bytes payload + 4 bytes of header and CRC). Please help me in this regard.
Regards,
Nagaraj
2018-02-22 11:28 PM
Y-Modem from the terminal side should send a whole packet.
I'd expect the target to be sending a 'C' byte to request a 1K+CRC packet