<danergo>
I had a working OpenOCD config but now it stopper working, although I had changed some wiring and environment location, etc.
<danergo>
Im trying to program a TI CC2652R with rpi.
<danergo>
Does it matter which gpio pins I use? Or I can chose freely?
<danergo>
Now it always says "jtag scan chain interrogation failed all zeroes"
<danergo>
And I now what this usually means, but I have not double but triple-checked my wiring
<danergo>
Unfortunately Im at a different place now, and I only have a basic multimeter
<danergo>
But it would be great if you could help me with 2 questions:
<danergo>
1. Gpio pin chosing freely or strict?(on rpi)
<danergo>
2. Which pins should be at which voltage initially? (Tms,tck,tdi,tdo)?
<danergo>
Thank you!
<Hawk777>
You need to connect the JTAG signals from your adapter to the proper pins on the target. It won’t work on just any pins.
Hawk777 has quit [Quit: Leaving.]
gnom has joined #openocd
<PaulFertser>
danergo: hey
<PaulFertser>
danergo: you should be free to choose gpios, yes. If you're in doubt you can use /sys/class/gpio to export a pin manually and change its value and test with a basic multimiter if it has any effect.
<PaulFertser>
danergo: initial state as configured by OpenOCD won't help you much as it quickly changes it during operation. For manual probing just use sysfs.
zjason has quit [Remote host closed the connection]
zjason has joined #openocd
nerozero has joined #openocd
tomtastic has quit [Ping timeout: 260 seconds]
tomtastic has joined #openocd
danergo has quit [Quit: Connection closed for inactivity]
rudar has joined #openocd
danergo has joined #openocd
<danergo>
Yes, thank you. Changing manually works, but openocd always reports the above error
<danergo>
Wiring is 300% OK
<danergo>
As long as I have to connect target's TDI to the pin defined as TDI in interface config
<PaulFertser>
danergo: right, TDI to TDI.
<PaulFertser>
danergo: so probably the target is unpowered? Or GND wire is faulty?
godSend23 has joined #openocd
<PaulFertser>
danergo: you can also check TDO pins temporarily switching direction to out for the test (after disconnecting from target of course).
<PaulFertser>
danergo: not sure what else to suggest. You're supposed to have some STM32 board around just to test JTAG ;)
godSend23 has quit [Remote host closed the connection]
godSend23 has joined #openocd
danergo25 has joined #openocd
<danergo25>
hi, thank PaulFertser, I have measered with connectivity function (beeper) my:
<danergo25>
GND, VCC wires on the module itself to the PI's other pins
<danergo25>
both are fine
<danergo25>
also check with this manner the TMS, TCK, TDO, TDI wires (measuring them to the other side, all fine
<danergo25>
On more thing, you might see some errors in my interface file:
<PaulFertser>
danergo: then it must be something else...
<PaulFertser>
danergo: unless you haven't mixed up gpio numbers and pin header numbers
<PaulFertser>
danergo: periph base must be corresponding to your rpi hardware version.
<danergo25>
no I haven't as this is a compute module, and on its motherboard there are no "Pin header numbers", only raw GPIO numbers
<PaulFertser>
danergo: what broadcom SoC does the compute module use?
<danergo25>
BCM2835
<danergo25>
same as the original RPi1
<danergo25>
periph base should be ok I guess
<danergo25>
speed_coeffs I have no idea :)
<danergo25>
maybe I'm not free to use those 29..32 pins?
<PaulFertser>
danergo: right, and speed_coeff shouldn't matter much if you're lowering down the speed with "adapter speed" anyway.
<PaulFertser>
danergo: depends on pin muxing. But you wouldn't be able to manipulate them with sysfs then.
<danergo25>
should I do some pin muxing before using openocd?
<danergo25>
my adapter speed is now 900kHz
<PaulFertser>
danergo: if sysfs export works I guess pinmuxing is not needed. You can alternatively try the sysfsgpio driver which is using exactly sysfs the same way you used it manually.
<danergo25>
hm. that is pretty much new to me
<danergo25>
"try the sysfsgpio driver": via some sysfsgpio config in interfaces?
<PaulFertser>
danergo: yes, and it's basically the same config as you use already.
<danergo25>
and I have to do anything before manually?
<danergo25>
like export, or anything?
<danergo25>
or I can just simply use the sysfsgpio, and see what happens?
<PaulFertser>
danergo: no, the driver does for you
<danergo25>
okay, I'll try this a bit later, thank you. I'll report back here in both cases
<PaulFertser>
danergo: good luck
<danergo25>
oh, thank you! :)
<danergo25>
PaulFertser: am I right that in sysfsgpio interface config I only need two lines?
<danergo25>
1.) adapter driver sysfsgpio
<danergo25>
2.) sysfsgpio_jtag_nums ...
<danergo25>
?
<danergo25>
in case I don't have any reset neither trst, nor srst
<danergo25>
btw, I'm using this in interface cfg: sysfsgpio_jtag_nums 31 32 29 30
<danergo25>
gpio readall reports the following for these gpios:
<PaulFertser>
danergo25: hm, that's different now, it captures something
<danergo25>
29 | OUT | Low |
<PaulFertser>
danergo25: see line 291
<danergo25>
29 | OUT | Low |
<danergo25>
okay, cool! this might happened earlier too, with the native config (without sysfsgpio)
<danergo25>
anyway, can you tell me the difference between sysfsgpio, and native?
<danergo25>
or if you have a link, I'd happily read
<danergo25>
I found, nevermind :)
<PaulFertser>
danergo25: native means manipulate gpio peripheral directly via MMIO. sysfsgpio just writes to files in /sys/class/gpio
<danergo25>
native seems better
<PaulFertser>
danergo25: faster, yes. But line 291 shows almost valid capture. Is it consistent, do you get same number each time? And does it match what you were getting when it was working nicely before?
<danergo25>
"nicely working" logs I don't have anymore I fear
<PaulFertser>
danergo25: btw, if you connect wires directly between raspberrypi board and your mcu you might need to connect more than one ground wires. And also you might need series termination resistors.
<danergo25>
well, that's really something I can't do now I'm afraid. this module only have a single GND pin
<danergo25>
resistors I could do, but I don't have scope, so it would be a huge guessing
<danergo25>
let me check your earlier question
<PaulFertser>
danergo25: yep, that's the problem...
<PaulFertser>
danergo25: that said, many jtag adapters just have the series resistors always there on the buffer outputs.
<danergo25>
it seems constant: Texas Instruments get recognized every time
<danergo25>
then with loglevel2, immediately comes an error about IR capture error
<PaulFertser>
danergo25: all the time?
<danergo25>
yes
<PaulFertser>
danergo25: btw, probably worth trying exactly the same openocd version that was working before.
<danergo25>
I'm trying with the same version
<danergo25>
moreover, on the same "computer" :)
<danergo25>
just in another physical location
<danergo25>
and wired differently
<danergo25>
and honestly, I have to tell you that wiring is far from optimistic
<danergo25>
but isn't there by any chance some config, to make this work, it doesn't matter if it takes 5 minutes to fully write the flash of the cc2652
<danergo25>
I'm just trying to make a proof-of-concept
<PaulFertser>
danergo25: I have an impression it's a signal integrity issue then.
<PaulFertser>
Probably length and location of wires matters, especially if you have no series termination.
<danergo25>
no series resistors applied, yes.
<danergo25>
but wires are the exactly same as when it worked
<PaulFertser>
danergo25: the problem with impedance matching is that jtag speed doesn't really matter if you get big enough ringing on TCK. And if you do, it'll be on each edge.
<danergo25>
well, I can add some resistors in serie, but then length of wires will be 2-3 times more than now
<danergo25>
as I can only solve it now with jumper-wires
<PaulFertser>
danergo25: sometimes it's good to try random related things.
<PaulFertser>
danergo25: 100 Ohm or so would be reasonable to try, and even just TCK line alone might help.
<danergo25>
huh, but if this is this fragile, can I expect this working after putting the whole thing onto PCB?
<PaulFertser>
Hard to tell without oscilloscope.
<danergo25>
yeah
<danergo25>
or I can 'kill the shark' by adding pads for optional resistors, and I can afterwards 100% make sure to work?
<PaulFertser>
danergo25: you make PCB with footprints for series resistors, then you put 47 or 100 Ohm there, then you run it and scope the signals and decide if you need it or if it works better with 0R.
<danergo25>
aham. Okay.
<danergo25>
I'll try adding 100Ohm to TCK.
<PaulFertser>
I can't promise you anything but I think signal integrity wouldn't be an issue with approach like that.
<danergo25>
I will have to search for it first, I have no idea where here there are resistors at all :)
<danergo25>
yes, Paul, I know, I won't blame you :)
<danergo25>
thank you so much for being here!
<PaulFertser>
Something else like 470 or 1k can be tried as well.
<danergo25>
okay, I'll report here once I had chance to do this, I guess it will be in the next 2-3 hours sometime
<PaulFertser>
danergo25: good luck! It's a good sign you're getting that "found: 0x3bb4102f" so some communication clearly happens. I am not sure if it would be possible if one of jtag lines wouldn't be connected, so at least that part is confirmed. Signal integrity still in question.
<PaulFertser>
Also you might want to try current git version or some old release. Who knows, probably you've forgotten which version was working back then or you think you were using one binary and in fact some other binary from other place was running. But so far my bet would be on signal integrity.
<danergo>
Binary is also the same, i moved this thing from placeA to placeB (current)
<danergo>
So binary, machine, target are all the same
<danergo>
Even wires are the same just i had to use different gpios now
<danergo>
And there are other stuffs joined to the pi as well
<danergo>
Thats the only difference
loki_val has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
godSend23 has quit [Ping timeout: 252 seconds]
danergo has quit [Quit: Connection closed for inactivity]
danergo25 has quit [Quit: Client closed]
danergo has joined #openocd
<danergo>
PaulFertser: 100R serial in TCK makes the situation worse: now 2-3 times out of 10 even the "tap/device found" message is missing too
Hawk777 has joined #openocd
danergo has quit [Quit: Client closed]
[itchyjunk] has joined #openocd
mjoerg has joined #openocd
mjoerg has left #openocd [ERC 5.3 (IRC client for GNU Emacs 27.2)]
nerozero has quit [Ping timeout: 252 seconds]
rudar has quit [Read error: Connection reset by peer]
c4017w has quit [Read error: Connection reset by peer]
<danergo>
sysfsgpio CAN recognize my target, whereas native doesn't.
<danergo>
why??
<danergo>
100% reproducability
<danergo>
sysfs also prints this: Info : This adapter doesn't support configurable speed
<danergo>
so what speed does it use then?
<PaulFertser>
danergo: slow speed
<PaulFertser>
danergo: so it wasn't able to recognise your target before?
<danergo>
before when?
<danergo>
before I moved?
<PaulFertser>
danergo: when you tried sysfsgpio driver today you said the result was identical to native.
<PaulFertser>
danergo: sysfsgpio driver just performs all the sysfs file manipulations, you can see that with strace.
<danergo>
yes, but I was lame, identical by that time meant that it can't flash the target
<danergo>
ahha
<danergo>
why can't we limit the speed?
<PaulFertser>
danergo: for native? You can, use "adapter speed" command.
<danergo>
true
<danergo>
sorry
<danergo>
so 1000 kHz is huge for this wiring
<danergo>
can I limit this let's say to 1Hz?
<PaulFertser>
danergo: did you have a chance to try series resistors on all data lines?
<danergo>
no, currently I have 100R in TCK only
<PaulFertser>
danergo: you can, why not. Without calibration it's unclear what exactly the speed is going to be but should be in the same ballpark.
<danergo>
I'll try to limit that to that slow and see
<PaulFertser>
danergo: and with sysfsgpio it behaves a bit randomly now?
<danergo>
well a bit randomly, yes, sometimes it detects my target twice (maybe because the commands i used)
<danergo>
sometimes only once
<PaulFertser>
danergo: I think for proper operation series resistors might be needed on all lines, especially with those strange cJTAG devices.
<danergo>
ahaam
<PaulFertser>
danergo: but does it always say about IR capture error after it sees JRC tap?
<danergo>
yes. that is constant
<danergo>
IR capture error; saw 0x00 not 0x01
<danergo>
but I have no idea on which port
<PaulFertser>
danergo: I thought ringing would just be ignored if it's not present on TCK as both sides would wait for the signals to go to steady state but who knows. At this point you can only guess as there's no scope to check.
<danergo>
yes
<danergo>
I'll try with a very low speed
<danergo>
now
<PaulFertser>
Worth a try.
<danergo>
this is very strange: even with as low as 1kHz, it can't detect the target
<danergo>
:O
<PaulFertser>
danergo: probably you can get access to an oscilloscope soon and then continue the quest.
<danergo>
is it possible that sysfsgpio works slower than 1kHz?
<PaulFertser>
danergo: unlikely, iirc it's like 10 times slower so for ~4 MHz I had with native that would be 400 kHz.
<PaulFertser>
Can't remember all the details now.
<danergo>
no problem
<danergo>
but in this case something very misterious thing is happening here, as native can't detect anything @1kHz, whereas sysfsgpio at least can detect the target
<danergo>
and the processor is ticking at least 700MHz, so the /10 would be 70MHz for sysfsgpio, but even /100 would be 7MHz
<danergo>
so the trick might be to communicate _faster_ ? :)
<PaulFertser>
danergo: 4 MHz was the maximum bitbanging rate I was getting with rpi1.
<danergo>
ah okay, I got you now
<PaulFertser>
danergo: OpenOCD reconfigures drive strength when using native bcm2835gpio driver, that might affect ringing too.
<danergo>
anyway, native doesn't work either with adapter speed, 1, 100, 1000, 10000, 100000
<danergo>
drive strength? how does it do that?
<PaulFertser>
danergo: by manipulating GPIO controller values that affect it.
<danergo>
I c, thx. And it doesn't do that by sysfsgpio?
<danergo>
or sysfs doesn't have those config options exported?
<danergo>
btw, honestly when I was struggling with this at the location where finally it started working, I had access to a scope there. And I checked the pins with the scope, but hadn't see anything suspicious. all signals seemed perfect
<danergo>
so you would recommend me to add another 100R-s to TDI, TDO and TMS?
<danergo>
100R-s doesn't make ANY change :((((
Hawk777 has quit [Quit: Leaving.]
<danergo>
native driver is deaf: doesn't even recognize my target
<danergo>
sysfs recognizes, but every time silly IR capture error
<danergo>
why is this so fragile?
<danergo>
:(((
<danergo>
wires are 3-5cm longs
<danergo>
I fear that in case I plan this to a pcb it will never work correctly
<PaulFertser>
danergo: but you'll have proper equipment when debugging PCB, right?
<danergo>
and " IR capture error; saw 0x00 not 0x01" doesn't help too much
<danergo>
yes, by then yes
<PaulFertser>
danergo: I can explain that error
<danergo>
but I don't want to manufacture the PCB until I have a working prototype
<danergo>
It can work slow, it doesn't matter, just please work :)
<PaulFertser>
And when you shift something to the IR register at the same time you get data shifted out of it. And JTAG standard says you should be getting 1 as the lowest bit of this fixed-length IR register. That's what the error is about, somehow shifting out of IR gives just 0 bits.
<PaulFertser>
IR is used to give the target instructions, and IR is always fixed length for a given target. But then depending on the instruction you get DR (data register) which has different length depending on current instruction.
<danergo>
on which pin do you see the shifted out data?
<PaulFertser>
TDO
<PaulFertser>
Yes, sysfs doesn't export any drive strength options.
<danergo>
okay, so in this case either TDO, either TMS, and TCK can be problematic I guess
<danergo>
in this IR error
<PaulFertser>
But you get IDCODE from DR register that's what makes it strange.
<PaulFertser>
danergo: do you have other JTAG adapter for testing how OpenOCD works?
<danergo>
let me check
<danergo>
I have a "CC-debugger" from TI
<PaulFertser>
Hm, and nothing supported by OpenOCD?
<danergo>
and an arduino mega with AVR2560
<danergo>
these are only what I'm having here unfortunately
<danergo>
and this problematic CC2652 :)
<PaulFertser>
danergo: does the target have physical TRST pin?
<danergo>
I don't think so:
<danergo>
it has 2-pin cJTAG and JTAG debugging; TDO with high-drive capability, TDI with high-drive capability, TMSC with high drive capability, TCKC (without notes about high-drive cap.)
<danergo>
it has JTAG Debug Access Port (DAP)
<danergo>
dedicated cJTAG (IEEE 1149.7) or JTAG (IEEE 1149.1) interface
<danergo>
The device boots by default into cJTAG mode and must be reconfigured to use 4-pin JTAG
<danergo>
mine: Error: 316 379 core.c:1426 jtag_validate_ircapture(): cc26x2.jrc: IR capture error; saw 0x00 not 0x01
<PaulFertser>
danergo: I have another idea to try: you can define trst and srst signals to those GPIO numbers you're using for e.g. TDI and TMS and then start without target config, connect with telnet, and use "jtag_reset" command to manipulate them slowly (1 means assert so the signal should go low), that you can check with DMM.
<PaulFertser>
I mean to see if bcm2835gpio driver manipulates the GPIOs in question.
<PaulFertser>
So far the only thing different to the time it was working is GPIO numbers used, right?
<danergo>
yes, correct
<danergo>
comparing to the configuration I used in the morning
<danergo>
now I have series 100R in every line
<danergo>
TMS, TCK, TDI, and also TDO
<danergo>
I'll try your idea tomorrow
<PaulFertser>
Do you use some breakout board to connect to those GPIOs?
<danergo>
yes.
<PaulFertser>
danergo: my current idea is that sysfsgpio works but too slow so operation can't be performed; and somehow bcm2835gpio just can't work so worth checking if it's actually manipulating all the lines and since you do not have a scope you need some steady signal, so reconfiguring those gpios for reset functions allows you to manipulate it manually.
<danergo>
CC2652 is soldered onto a breakout board, and some jumper wires are soldered onto the breakout board, which are then attached to the RPI (through a series resistor of 100R)
<danergo>
aha, okay
<danergo>
so maybe this is some kind of weird limitation of gpios on this RPi
<PaulFertser>
I mean the CM doesn't have a header for jumper wires, you need some sodimm socket for it, right?
akaWolf has quit [Ping timeout: 268 seconds]
<danergo>
ah, yes, yes. I have a motherboard for it: