Forum : ARM
| Post Information | Post |
|---|---|
|
March 20, 2007 - 3:55pm
|
Below are the relevant details for STR9x JTAG Boundary Scan Error: 1) Actual Error given by RIDE (Raisonance Integrated Development Environment): STR9 Boundary Scan TAP IdCode mismatch: 0x1457F040 2) When it works the RIDE response is : Connection to Target OK. Target’s IdCodes are: BS: 0x1457F041 CPU: 0x25966041 PLD: 0x04570041 => Note that BS Code is different from line item 1 by last BIT! 3) It gives an error about 80% of the time and works the other 20% time when using an 8 MHz Oscillator => Only long enough to load the code but RIDE fails to load debugger! 4) The error occurs both on the Raisonance STR912F Daughter Card (when I changed the Crystal from 25 MHz to 8 MHz) and on my Prototype Board, which also has an 8 MHz Oscillator. 5) The Oscillator has a 3.3 Volt output and is connected to X1_CPU pin (X2_CPU is grounded). The STR912FW44 X1_CPU input with a 178 ohm series resistor between it and the Osc has a 3.4 Vpp drive signal with no under or overshoot! => Is this to big, nothing in the data sheet or Ref Manual???? 6) The Raisonance STR912F Daughter card works fine with a 25 MHz crystal. => This has a 2.5 Vpp signal as X1_CPU input! 7) Note, if the Boundary Scan Error occurs, the RIDE Development System will not work properly, so I can’t load and debug code properly! 8) And, I have slowed the JTAG clock speed to 10X or more below the uC speed and the system still fails as described above! Any Ideas??? Thank you, |
Hi,
What is the slowest JTAG speed you tried? Please try 400KHz if you haven't already done it.
Also, please try to debug using this example from RIDE: "c:\ride\examples\STRx\test\..." on the REva daughter board with the modified oscillator. (you just have to change the derivative in the target options.make sure you successfully erased the part with RFlasher before starting your test) When you tell me if it works or not, then I should be able to make some tests and try to reproduce your problem here.
Best Regards,
Vincent
Hello Vincent,
1) I changed the JTAG to 400KHz
2) I loaded TEST
3) I changed Target type to STR912FW44
4) No Change => still gives same errors as described in previous message!
Note that I'm using RLINK Pro with Serial number dngSR7P00000033 and RIDE is Version 06.10.22 Build Number: BN746-STR7-ARM
Thank you,
mschott
Hi,
First, please note that there is a patch for STR9 for BN746. It is very probably NOT related to your problem, but you might need it later. Therefore, I recommend you to download it from our website and install it.
I will solder a 8MHz oscillator on a board here and try to understand what happens. I'll let you know when I have any more information.
Best Regards,
Vincent
Hello Vincent,
1) I have downloaded and installed your BN746 patch and just as you predicted, it has no affect on the present issue defined above.
2) Also, I have been able to make the JTAG work long enough (works about 20% of the time) to erase the FLASH, just in case it had something to do with programming STR9's PLL Clock and not allowing it to settle before enabling it, but this also has no effect.
3) I then changed back from the 8 MHz to the 25 MHz Crystal on the Raisonance STR9X Daughter Card, and everything works fine! Unfortunetly my Target Application requires an 8 MHz Clock!
4) Also, I have contacted STMicro and they are adamant that it is not a problem with the STR9x uC!
Thank you,
mschott
Hi,
I could reproduce your problem and I think I understood it. Please try these DLLs, which seem to solve it here:
ftp://www.raisonance.com/pub/forum/STR9_8MHz_fix_BN746_070322/STR9_8MHz_BN746_fix_070322.zip
Copy the 4 files (3 dll and 1 exe) in your "c:\ride\bin" folder. Rename/save the old ones before that. And then it should be OK.
I'm waiting for your feedback before I commit the change for the next version of RIDE.
Best Regards,
Vincent
Hello Vincent,
The new files and RlinkPro now work with an 8MHz Clock, Excellent!
Can you give me a breif explanation?
Thank you,
mschott
Hi,
I'm glad to hear that it works. I'll include the fix in the next version of RIDE.
The explanation would not be of much use to you. Just a problem of duty cycle that was not documented in the ST spec. :/
My workaround slows the com down a little, but I don't think it will even be noticeable for the end user. (that's you :) )
Best Regards,
Vincent