Fake Blue Pill
I am a big fan of the blue pill design boards. They are very good in terms of price / features. Actually, my love for them is noticeable from the April Fools article about pedal firmware for playing the balalaika .
It is in the order of things to open a box with such boards and quickly take one to solve some problems. That's right, I recently took another board, flashed it with a well-debugged and tested “firmware” and ... got an unidentified USB device. I took another fee, “flashed” it, the device worked there. There would be an end, but I wonder what the matter is. Therefore, as the weekend came, I took up a detailed study of why it does not work.
In general, before “flashing” the boards, I am convinced that the test, poured by the manufacturer, is working: the LED is flashing. So I was sure that the processor was generally alive. What then is to blame? Perhaps the USB line or quartz.
')
The lines were all fine, the quartz did not start. But it may not start for a variety of reasons. Its launch is performed programmatically, already in the depths of the main () function. Well, fine, we start debugging the program.
All anything, but the debugger does not exit the main () function. The program "hangs" somewhere between the launch and this function.
We stop the program: quite expectedly, we are in the HardFault handler.
What brings us here? We reset the address counter:
And we begin to gently walk through the program. Here, on this line, everything dies; we use at least Step operation, even Step Over .
Merry Keil ... Well, nothing. We reset everything once again (RST), click the “mouse” on the disassembler window and step there. In this case, we can understand that everything dies inside the __scatterload function.
In general, if everything dies in this function, there is already a reason to look at whether the type of controller is confused. But no, that's right (I also checked the settings, but this firmware works in other boards).
Good. Again, everything is reset and we are already tracing this function. After a few tests, freezes and discharges we find the guilty line ...
Yes Yes. Everything dies while keeping the registers on the stack. At the same time, on the left you can see that SP is equal to 0x200030A0. We look at the documentation for the controller:
We look, what window is selected for SRAM:
That's right. The stack pointer (SP) is in the allowed range. So what is to blame? Let's try to cheatfully change the SP value from 0x200030A0, say, to 0x200020A0, since the debugger allows it ... Chpok! The hang in the specified line has stopped! So, our memory crystal is not 20 kilobytes. And how much? After checking several times, we find out that the last working value of SP is 0x20002800. That is, 10 kilobytes. This corresponds to the STM32F103C6 crystal. Before us sawn chip. Alas.
All anything, but the boards from this lot in my rather big box are easy to distinguish. They have a special color of jumpers and a very beautiful emerald LED (the others have a less pleasant shade of green). Therefore, they easily stand out from the pile of other cards. Of course, I checked them. Of course, the whole party was cut through (I took a dozen).
What to do with this is not clear. When I got three pieces in the top ten boards that didn’t have a regular test: the LED did not blink (therefore I’m not checking them selectively, but totally), I was butting the seller for a week. He "turned on the fool." Constantly interested in what I want to do, promised to help with advice. And I again and again repeated to him that I stupidly connected to the power supply, seven motherboards blink an eye, three - no. So they are dead. And he again his barrel organ. And so a week. But there everything was obvious. Did not pass the regular test. Here the regular test passes, it does not need a lot of memory. How to prove that a fake has come is not clear. And if you can prove it, then all the same, according to the rules of Ali Express, you need to send the goods back. In general, everything looks like hopelessness. And most importantly, the final seller did not have malicious intent. I took another batch from him, later. Everything is fine there. He himself was let down.
Anyway, I inform the public that this is how it happens. Check the boards not only for general performance, but also for real performance. True, what to do if there is a discrepancy is not clear.
The article has another practical use. It shows how you can quickly find the reason why suddenly the board does not work if the matter is not the complete inoperability of the controller (it responds to the SWD debug port).
It is in the order of things to open a box with such boards and quickly take one to solve some problems. That's right, I recently took another board, flashed it with a well-debugged and tested “firmware” and ... got an unidentified USB device. I took another fee, “flashed” it, the device worked there. There would be an end, but I wonder what the matter is. Therefore, as the weekend came, I took up a detailed study of why it does not work.
In general, before “flashing” the boards, I am convinced that the test, poured by the manufacturer, is working: the LED is flashing. So I was sure that the processor was generally alive. What then is to blame? Perhaps the USB line or quartz.
')
The lines were all fine, the quartz did not start. But it may not start for a variety of reasons. Its launch is performed programmatically, already in the depths of the main () function. Well, fine, we start debugging the program.
All anything, but the debugger does not exit the main () function. The program "hangs" somewhere between the launch and this function.
We stop the program: quite expectedly, we are in the HardFault handler.
What brings us here? We reset the address counter:
And we begin to gently walk through the program. Here, on this line, everything dies; we use at least Step operation, even Step Over .
Merry Keil ... Well, nothing. We reset everything once again (RST), click the “mouse” on the disassembler window and step there. In this case, we can understand that everything dies inside the __scatterload function.
In general, if everything dies in this function, there is already a reason to look at whether the type of controller is confused. But no, that's right (I also checked the settings, but this firmware works in other boards).
Good. Again, everything is reset and we are already tracing this function. After a few tests, freezes and discharges we find the guilty line ...
Yes Yes. Everything dies while keeping the registers on the stack. At the same time, on the left you can see that SP is equal to 0x200030A0. We look at the documentation for the controller:
We look, what window is selected for SRAM:
That's right. The stack pointer (SP) is in the allowed range. So what is to blame? Let's try to cheatfully change the SP value from 0x200030A0, say, to 0x200020A0, since the debugger allows it ... Chpok! The hang in the specified line has stopped! So, our memory crystal is not 20 kilobytes. And how much? After checking several times, we find out that the last working value of SP is 0x20002800. That is, 10 kilobytes. This corresponds to the STM32F103C6 crystal. Before us sawn chip. Alas.
All anything, but the boards from this lot in my rather big box are easy to distinguish. They have a special color of jumpers and a very beautiful emerald LED (the others have a less pleasant shade of green). Therefore, they easily stand out from the pile of other cards. Of course, I checked them. Of course, the whole party was cut through (I took a dozen).
What to do with this is not clear. When I got three pieces in the top ten boards that didn’t have a regular test: the LED did not blink (therefore I’m not checking them selectively, but totally), I was butting the seller for a week. He "turned on the fool." Constantly interested in what I want to do, promised to help with advice. And I again and again repeated to him that I stupidly connected to the power supply, seven motherboards blink an eye, three - no. So they are dead. And he again his barrel organ. And so a week. But there everything was obvious. Did not pass the regular test. Here the regular test passes, it does not need a lot of memory. How to prove that a fake has come is not clear. And if you can prove it, then all the same, according to the rules of Ali Express, you need to send the goods back. In general, everything looks like hopelessness. And most importantly, the final seller did not have malicious intent. I took another batch from him, later. Everything is fine there. He himself was let down.
Anyway, I inform the public that this is how it happens. Check the boards not only for general performance, but also for real performance. True, what to do if there is a discrepancy is not clear.
The article has another practical use. It shows how you can quickly find the reason why suddenly the board does not work if the matter is not the complete inoperability of the controller (it responds to the SWD debug port).
Source: https://habr.com/ru/post/459136/
All Articles