my Primer1 causes me a little confusion when I try to re-program or debug the program memory. The Device works, it turns on after pressing the button and i can see the CircleOS graphic on the lcd.
Windows recognizes the Primer if i connect or disconnect on the USB. But Ride7 says:
"target power failure measured: 0.000000V"
Is there any one else who knows that issue or even had figured it out?
I read another thread in this forum, where the cause was a broken R17 on the Primer PCB. I've checked the R17/R18 point on my hardware, the potential there is about 1.6V Seems okay to me.
thanks for your response. I've checked the voltage at pin54, there is 1.6V potential also. So if this is not a RLink firmware or Ride7 related issue, the ST7 must be broken, am i right?
Yes, I suspect a hardware problem in the ST7. (The firmware is probably fine if you can read the Serial Number.)
It can happen that one or several IOs of the ST7 are burned but the rest (clock, CPU, USB, memories, etc.) still works. We have seen that a few times, but it was after customers plugged the RLink on target boards with out-of-spec voltages. (more than 12V !) I cannot imagine how this could happen in a Primer, but I also cannot imagine another explanation to what you observe...
Did you ever connect any external device or power to your primer?
Did you manage to connect to the STM32 one or more times and after some time it started failing, or did you see the error at the first attempt to program/debug? (you see CircleOS running, which proves that the RLink was able to program the STM32 during production, as this is done in-situ on the production line for validation)
Here is a way to check if it's just the pin54 or more than this that is broken:
First, you must make sure that you are using the latest version of Ride, which is available on our website since last week.
Then, open these three files in a text editor: (save them first) <Ride>\sim\ARM\STM32_Primer1_CircleOS.sim <Ride>\sim\ARM\STM32F103RBVT6.sim <Ride>\sim\ARM\STM32F103RBVT6_CircleOS.sim In all three files, search for "VCCmin=25" and replace it by "VCCmin=0".
That will disable the voltage check that Ride performs on VCC before connecting to the STM32.
If that solves the problem, then we can assume that pin54 of the ST7 is burned and only that. If that doesn't solve the problem, then there is more than this that is burned or maybe the problem is completely different, and we will make a few other tests, or maybe just exchange the primer with a new one.
I cannot imagine how this could happen in a Primer, but I also cannot imagine another explanation to what you observe...
That makes me wonder, too.
VincentC :
Did you ever connect any external device or power to your primer?
No, I connected the Primer to USB - nothing else.
VincentC :
Did you manage to connect to the STM32 one or more times and after some time it started failing, or did you see the error at the first attempt to program/debug?
It fails since my very first trial. In debug and program mode either.
VincentC :
Here is a way to check if it's just the pin54 or more than this that is broken:
Thank you very much for this suggestion. I will try this today and give feedback then.
VincentC :
If that doesn't solve the problem, then there is more than this that is burned or maybe the problem is completely different, and we will make a few other tests, or maybe just exchange the primer with a new one
I have got them yesterday from the stm32circle download page included in the Primer CD files. It is difficult to verify because most of the links my searching engine found are actually invalid.
seems to be a bug in CircleOS -- it shows BAT 0V in "Config"->"Test" too. Installed Primer1 CircleOS update, "About" shows CirlceOS 3.3 (should be 3.5).
Seems to have another bugs too -- Circle_Mgr somehow shows 32 kb flash less (shows 72 kb when no apps, should be 104 kb), but that's another theme, I guess.
I hope you can tell me, why the files you named are different to those i found?
By the way - I made an attempt in modifying the existing files and start a debug session with "Toggle_with_CircleOS". The "target power failure" is not getting recognized anymore, but the OPI driver is reporting then:
Error: Execution out of debugging limitation PC=0xFFFFFFFE Terminating debug session.
Do you have any idea of what is going wrong again?
First the simfile indicated by Vincent might be a typo mistake. In french keyboard B and V are close!
The file you have changed should be the good one for the test suggested by Vincent. I will let him tell what he think about the result of your test.
But does this error happen with a project example from Raisonance (which one)? Did you tried other, I tried here with a primer1 and it was ok with project: <ride>\Examples\ARM\Primer\STM32\toggle_with_CircleOS\toggle_with_CircleOS.rprj
first i appreciate your engagement. Ok, i guessed it was a typo mistake. Unfortunately, this has not solved anything. The example project you suggested is the one that does result in the observed OPI driver error. Additionaly i tried the .bat files for automatic firmware restoring. There is no error message in the cmd window, all points terminate OK but there is no new program running on the device. Perhaps something died in the primer hardware. Its Primer1 V1.2 and some parts seem like they have been soldered manually (snatchy positioning), is this possible?
Can you let me know the serial number of the Rlink embedded in the primer1. To do so use "connect to RLink and Read serial number" from "RLink advanced options". I would check if there is something unusual in this product.
Can you let me know the serial number of the Rlink embedded in the primer1.
Of course. It is: dngWNYe00001582
I would check if there is something unusual in this product.
In my (long time ago) last post I wrote about manually soldered parts on my Primer1, I will have to examine that. The snatchy positioned parts are all askew in the same angle, so it was possibly the whole PCB got turned out of position a little bit. But this might not be the reason my Primer is not working yet. So i am looking forward to your response.
