shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
ormaaj has quit [Quit: Bridge terminating on SIGTERM]
Jybz[m] has quit [Quit: Bridge terminating on SIGTERM]
barath has quit [Quit: Bridge terminating on SIGTERM]
noperator[m] has quit [Quit: Bridge terminating on SIGTERM]
LinuxHackerman has quit [Quit: Bridge terminating on SIGTERM]
Jybz[m] has joined #openocd
shoragan[m] has joined #openocd
ormaaj has joined #openocd
LinuxHackerman has joined #openocd
barath has joined #openocd
noperator[m] has joined #openocd
Steve45 has joined #openocd
<PaulFertser>
Steve45: hi. Please do NOT paste more than 3 lines in a channel
<PaulFertser>
Steve45: use same pastebin service instead.
<PaulFertser>
Steve45: also please answer the question about your hardware, it seems odd you mention Cortex-M0 cores using JTAG as all common M0 MCUs can't be debugged using JTAG (some have boundary scan though).
<Steve45>
Hi Paul, Thanks for the suggestions. First off, I have no idea what "pastebin" is. If it is the freeware program I found on the net then I can't install it on my work computer. I tried using the openocd mail listserv but it keeps rejected my messages event though I am registered. We have used JTAG to debug ARM M0+ for a long time now with
<Steve45>
the Beyond Debug Key, this is our first attempt to use another product (flyswatter2), so I am not sure why you claim the the M0+ cannot be debugged with JTAG.
<Steve45>
Judging by what I see on the open ocd output, I can debug the last M0+ in the chain, but not the first three.
Steve45 has quit [Quit: Client closed]
* karlp
shrugs, guess they'll figure it out then
<PaulFertser>
Yep, odd communication.
<karlp>
beyond logic looks like they sell IP for m0s, so they may have stuff with jtag added back on? *shrugs*
<PaulFertser>
"why you claim the the M0+ cannot be debugged with JTAG." but nobody claimed that
<PaulFertser>
That said, I think there's nothing inherently complex about implementing a Cortex-M0+ core with JTAG support, it seems the majority of vendors just opt not to do that to save costs.
<karlp>
I thought I'd seen it at arm level that they were all swd only, but maybe there's some that speak jtag around.
<PaulFertser>
Some old LPC M0 parts supported JTAG for BS.
<karlp>
well, guess I waylaid the conversation with talk of multidrop swd then.
barath has quit [*.net *.split]
Haohmaru has quit [*.net *.split]
thinkfat has quit [*.net *.split]
sbach has quit [*.net *.split]
bq has quit [*.net *.split]
borneoa_ has quit [*.net *.split]
sbach has joined #openocd
Haohmaru has joined #openocd
borneoa_ has joined #openocd
thinkfat has joined #openocd
bq has joined #openocd
barath has joined #openocd
Haohmaru has quit [Remote host closed the connection]
wingsorc has joined #openocd
Steve39 has joined #openocd
<Steve39>
Our M0+ parts do have the optional JTAG interface. When I did a boundary scan with openocd I do see all 4 cores. The problem is that when I create the daps/targets I get the error about no MEM-APs on the first three cores in the chain.
<Steve39>
One of our hardware people theorized that there needs to be extra JTAG clocks to push out the data through the daisy chain. I am not sure this is the case since openocd seems to understand how to deal with daisy chained devices.
<PaulFertser>
Steve39: are you using some custom M0+ parts?
<PaulFertser>
Steve39: of course OpenOCD gives enough clocks to run through the whole chain.
<PaulFertser>
Steve39: I suggest you make a test run without defining any taps, sometimes looking at autodetection results gives more clues.
<Steve39>
our M0+ parts are stock and we have the optional debug blocks
<PaulFertser>
Why do not you mention the part name?
<Steve39>
they are embedded in a custom ASIC we are developing
<Steve39>
I already did a scan with openocd (autodetection), it wroked fine and showed my 4 M0+ cores
<PaulFertser>
With same irlen?
<Steve39>
yes
<PaulFertser>
I'd take a look at
<PaulFertser>
-d3 log with all four targets defined then.
<Steve39>
ok, I can generate that, sure you dont want -d4?
<Steve39>
I have already seen that log, I can't see where it goes south
<Steve39>
open ocd loops through all 256 MEM AP ids looking for a valid ID code
<Steve39>
but none is discovered, the last target gets a valid code for number 0
<PaulFertser>
You can also manually do "dap info 0" from telnet.
<PaulFertser>
And select different current target with "targets".
<Steve39>
can I embed "dap info 0" in the config script?
<PaulFertser>
Steve39: it needs to be run after init.
<PaulFertser>
Steve39: so why do not you show a -d3 log? I think -d4 gives too many details about specific debug adapter.
<Steve39>
the d3 log just shows a bus walk through all the possible MEM-AP ids
<Steve39>
they all return 0
<Steve39>
except for the last core
<PaulFertser>
Do you not want us to see it?
<Steve39>
I have no issue with that, but I will have to figure out the pastebin issue first
<Steve39>
let me read the link you sent
<PaulFertser>
Get some COTS MCUs that support JTAG, e.g. stm32f7, make a chain out of them, try OpenOCD with that chain, and compare the logs to what you're getting with your custom cores.
<PaulFertser>
I'm sure it used to work properly, but chances are there's a generic regression. Would be nice to have something easily reproducible for testing.
<Steve39>
of course; here is an interesting observation: I just did another run with telnet and the "dap info 0" command showed a valid MEM-AP, but when I tried 1, 2, 3 then it failed with the ID register 0x00
<PaulFertser>
I suggest you first get it working with something not custom.
<PaulFertser>
If it's a regression then it should be easy to bisect.
<Steve39>
ok, I will see if we can move in that direction; the problem is that the hardware is a very long way away from me and I have to have remote people do that work.
<PaulFertser>
Steve39: that's interesting. So DAP communication works but no AP is found.
<Steve39>
yes
<PaulFertser>
Steve39: I wonder what happens if you define just a single dap and target. If it's going to be working with just the last tap or if it can work with the other taps too.
<Steve39>
except on the last one
<PaulFertser>
Or if it fails in exactly the same way.
<Steve39>
I can do that, do i keep the jtag definitions?
<PaulFertser>
Steve39: yes
<PaulFertser>
Steve39: btw, do I understand it right that you have some other hardware+software working nicely with exactly the same target?
<PaulFertser>
Does it also assume that there're only 4 taps each having 4 bit IR length?
<Steve39>
ok, just finished that run, commented out all dap and target except the first and we still cannot find the MEM-AP on that target
<Steve39>
your questions: we do have software hardware running on all the m0 cores
<Steve39>
yes to second question
<PaulFertser>
No, I mean JTAG debug for the cores.
<PaulFertser>
Not software running on the cores themselves.
<Steve39>
ah, that, early simulation validated the JTAG, but we have not used the Beyong Key on this one
<Steve39>
all the cores are identical to each other as far as hardware
<PaulFertser>
Steve39: can you attach two of those things in the chain? I wonder if both the 4th and the 8th cores are going to be detected, or just the 8th.
<Steve39>
I cannot physically do that as this is embedded inside an ASIC
<PaulFertser>
Steve39: but you can connect two of those ASICs in a chain.
<Steve39>
correct
<PaulFertser>
So I suggest you try it that way.
<Steve39>
oh, wait, no I cannot daisy chain two of those ASICs
<PaulFertser>
It might be that there's something extra special about the chain inside the ASIC or about the 4th core.
<PaulFertser>
Why not?
<Steve39>
would require a board mod, which would be fairly complex
<PaulFertser>
Hm, I meant just two boards side-by-side with jumper wires connecting jtag.
<Steve39>
the JTAG chain in the ASIC, is simple enough,
<PaulFertser>
I suggest you try with any popular MCU you have handy. Connect two of them in the chain and see OpenOCD examining both happily. Or not. You gotta get some more data to be used as a reference point.
<Steve39>
the picture shows how our is set up (basically)
<PaulFertser>
You're saying you're 100 % sure that the ASIC has just the 4 taps and that they're all identical. That might be true but then I have no idea how it might be possible for OpenOCD to properly work with just the last device there.
<Steve39>
I was merely referring to the picture as it was handy
<PaulFertser>
So I'm trying to invent some ways which would provide more clues.
<Steve39>
of course
<Steve39>
actually, now that you mention it, there is another difference I see in the schematics
<Steve39>
there is a tri state buffer with an enable line
<Steve39>
I wonder if only the fourth core is enabling that line
<PaulFertser>
You can also try running OpenOCD 0.10.0 for comparison (you'll have to amend the config slightly, as dap definition back than was implicit) but I think it's likely to give you identical results: just the fourth core examined. Who knows though, no harm trying.
<Steve39>
sure, I give that a try as well
<PaulFertser>
The core itself controlling whether its SWJ debug module is connected or not? That might explain it, yes.
<PaulFertser>
(or whatever ARM calls it, I do not remember exactly, I mean the part that connects DAP to external debug hardware)
<Steve39>
ok, it seems I have some homework to do, I will run off and do that. Thanks for your time
<PaulFertser>
Steve39: good luck with your project :)
<Steve39>
thanks, I will need it
kraiskil has quit [Ping timeout: 268 seconds]
SteveMarple has joined #openocd
sbach has quit [Read error: Connection reset by peer]