flash loader doesnot recognize the processor

[mehmet.karakaya]

Posted on November 01, 2010 at 21:50

flash loader doesnot recognize the processor

[Tesla DeLorean]

Posted on May 17, 2011 at 14:13

It's sad to see that don't have a real POR circuit or a JTAG/SWD header.

I guess I'd start by connecting a known working USB-to-SERIAL(CMOS-3V) adapter to USART1 instead of the the MAX232 and try to confirm I could reliably communicate with the HW. I'd try connecting directly with an application that could send the 0x7F the boot loader is looking for, and test out the commands/functions of the boot loader. I'd upload some code to further test out the system. If the system is not resetting reliably, I'd add a real POR circuit. One that thresholds the 3/3.3V supply as it's coming up and maintains the reset for a known period (in the order of 100-200 ms, and 2.8V say)

[mehmet.karakaya]

Posted on May 17, 2011 at 14:13

hello Clive1 , thanks for reply

the RS232 conection is ok becouse the application I downloaded ( while the flash loader demo was still functioning ) is running and it has a serial protocol which is comunicating perfectly the strange thing is if I shut down at night and power up in the morning the flash loader demo is recognizing the processor  - ( only recognize, no other function ) if there were some ''cold solder '' , it should not communicate with my application either

[Tesla DeLorean]

Posted on May 17, 2011 at 14:13

As things go, the STM32 boot loader is pretty stable.

It uses the internal HSI clock, sets up the PLL, and times the bits of the 0x7F message to auto-baud the data rate. It does this once at reset, so if that fails it is best to reset and start over so it gets the right rate. I didn't see a reset switch/button, if you have some way of manually grounding the reset, use that to generate a reset rather than dealing with how quick the supply comes up from an ON/OFF/ON cycle. On the POR side, Microchip has a number SOT packaged reset circuits (MCP120/130), I think ST and Dallas have some too, but I'm less familiar with those. If you have someone with SMT soldering experience and an inspection microscope they should be able to check and rework any solder issues. It doesn't look like you have and via-in-pad issues to wick solder away, and it looks to be a manual build.

[mehmet.karakaya]

Posted on May 17, 2011 at 14:13

hello ,

I looked at the oscilloscope to the Rx and Tx of uC after I reset ( I have reset jumper ) , when I start flash loader I see 2 characters coming and the micro is sending some bytes back but no recognition this time I tried something else 0x7f   is  ascii ''Del''   - I send Del with hyperterminal ( 9600 baud ) response is ''|'' which is 0x7c in ascii table is this a ''sign of life'' ? PS. I checked every pin of micro with avometer - the soldering is ok

[Tesla DeLorean]

Posted on May 17, 2011 at 14:13

Parity is important, consider looking at RealTerm (SourceForge)

9600 8E1 or 115200 8E1 (EIGHT BIT, EVEN PARITY, ONE STOP) At reset I wouldn't expect the STM32 to send any data out, it waits for input. First Sending 0x7F should illicit a response of 0x79 (ACK) Then Sending 0x01 0xFE should illicit a response like 79 22 00 00 79 (hex) or  79 21 00 00 79 (GET_VER_ROPS_CMD) Sending 0x02 0xFD should illicit a response like 79 01 04 10 79 (hex) (CHIP ID) The NACK response 0x1F

[mehmet.karakaya]

Posted on May 17, 2011 at 14:13

hello Clive1 ,

I wrote a simple visual basic form with 2 buttons and a listbox 1st button send 0x7F and second button send 0x01 , 0xfe I additem every character received to the listbox I reset the micro with short circuiting reset cap with jumper I send 0x7f  -> response 0x7f I send 0x01 , 0xfe -> response is single byte which is 0x79 I send 0x02 , 0xfd -> response is again single byte which is 0x79 sending again 0x7f returns 0x1f what can I else do ?

[Tesla DeLorean]

Posted on May 17, 2011 at 14:13

Quickly retesting an STM32F103RBT6 on a MINI STM32

Using RealTerm to send numbers at 115200 8E1 [7F] 79 [01 FE] 79 22 00 00 79 [02 FD] 79 01 04 10 79  If you are unable to duplicate equivalent results for your part, you are going to have a heck of a time writing a firmware into the device. Next you should probably look at voltages, reset lines, and IO pins.