Thanks for the hint - it was in fact the x-loader as it seems. I unpacked and used the one from ubuntu and it now should work.
I did use the 5.0 version already, but even in this one the jtag was disabled (which is funny though as you can see the devices on the scan chain) - the ubuntu one did work nevertheless.
I got a busblaster v2 from seeed and tried to use it to debug something using openocd on my BeagleBoard xM I connected it quite similar to the description of the pandaboard in the docu section - but unfortunately I have no success.
Has anyone ever tried this, or atleast can help me figure out what's wrong. I double checked the wiring, also trying to connect all of the busblasters pins and also connecting it like the flyswatter beagle adapter cable does - always with the same result.
openocd -f /home/peter/busblaster.cfg -f board/ti_beagleboard_xm.cfg Open On-Chip Debugger 0.5.0 (2012-01-24-22:59) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 2000 kHz 10 kHz Warn : dm37x.dsp: huge IR length 38 trst_only separate trst_push_pull Info : max TCK change to: 30000 kHz Info : clock speed 10 kHz Info : JTAG tap: dm37x.jrc tap/device found: 0x2b89102f (mfg: 0x017, part: 0xb891, ver: 0x2) Info : JTAG tap: dm37x.dap enabled Warn : Invalid ACK 0x6 in JTAG-DP transaction Polling target failed, GDB will be halted. Polling again in 100ms Polling target failed, GDB will be halted. Polling again in 300ms Polling target failed, GDB will be halted. Polling again in 700ms Polling target failed, GDB will be halted. Polling again in 1500ms Polling target failed, GDB will be halted. Polling again in 3100ms Info : accepting 'telnet' connection from 4444 Polling target failed, GDB will be halted. Polling again in 6300ms > targets TargetName Type Endian TapName State -- ------------------ ---------- ------ ------------------ ------------ 0* dm37x.cpu cortex_a8 little dm37x.dap unknown Polling target failed, GDB will be halted. Polling again in 6300ms > scan_chain TapName Enabled IdCode Expected IrLen IrCap IrMask -- ------------------- -------- ---------- ---------- ----- ----- ------ 0 dm37x.dap Y 0x00000000 0x00000000 4 0x01 0x0f 1 dm37x.arm2 n 0x00000000 0x00000000 4 0x01 0x0f 2 dm37x.dsp n 0x00000000 0x00000000 38 0x25 0x3f 3 dm37x.d2d n 0x00000000 0x00000000 4 0x01 0x0f 4 dm37x.jrc Y 0x2b89102f 0x1b89102f 6 0x01 0x3f 0x0b89102f 0x0b89102f Polling target failed, GDB will be halted. Polling again in 6300ms Polling target failed, GDB will be halted. Polling again in 6300ms Polling target failed, GDB will be halted. Polling again in 6300ms > reset init 10 kHz JTAG tap: dm37x.jrc tap/device found: 0x2b89102f (mfg: 0x017, part: 0xb891, ver: 0x2) JTAG tap: dm37x.dap enabled Invalid ACK 0x6 in JTAG-DP transaction in procedure 'reset' > amdm37x_dbginit dm37x.cpu target not examined yet Runtime Error: target/amdm37x.cfg:194: in procedure 'amdm37x_dbginit' in procedure 'cortex_a8' called at file "target/amdm37x.cfg", line 194
Why is the state always 'unknown', is this related to the "Warn : Invalid ACK 0x6 in JTAG-DP transaction" message?
I totally agree with s3c - capturing some ir-signals somewhere in the wild, dumping and analyze them on the pc, change them and replay them to the original target would definitely be fun (and of course enable some pranks
-> So a standalong capture/replay interface would be nice - because people often get quite suspicious when you point around with some 'naked' hardware attached to a laptop
Would be nice to know wether this might be possible by using another firmware version or wether the hardware would have to be changed as well.
I'm looking for the cheapest method to transmit some data wireless. I want to transmit only a few bits, mainly 1/0 status indicators over a distance of about 10m and the main criteria of success is price, nothing else
And another one: This patch makes BBmode more stable, especially for subsequent calls. Without this patch, the script might get confused if the Buspirate answers to early with an BBI01
And I attached also my I2C-Testscript, which writes and reads an eeprom
thanks for your script Sean, unfortunately there are some bugs - and I fixed two of them. 1) In BitBang.py you have to compare data to chr(0x01) as data is a string and does not get converted to a number unfortunately 2) Don't use
The operators ``is`` and ``is not`` test for object identity: ``x is y`` is true if and only if *x* and *y* are the same object.
Unfortunately you use is quite often :/
I attached a patch against your git latest tree. Do you need some help in the python section? I guess I could bring the code up to date (without killing my bootloader again )) if yes - just contact me.
Or should I fork your git tree and you pull my changes?