jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Hellsenberg is now known as Hell__
Hell__ is now known as Hellsenberg
pke has joined #glasgow
<pke>
PIC32 Jtag was driving me mad in the past week. It turns out the main problem was a flaky connection on TDO. Now the target is identified during the scan. However jtag-mips GDB asserts out, for some reason ("screenshot in link") https://imgur.com/gallery/NHIu9fH and i have no idea where to look.
<pke>
During the troubleshooting i broke out jtag from my ice stick's ft2232h and whit openocd i'm able to halt the same target.
<pke>
I can provide logic analyser traces from the jtag if would help.
<pke>
something to do with scan_dr_length
<whitequark>
pke: let's see
<whitequark>
pke: are you sure this is EJTAG?
<whitequark>
the IMPCODE register looks completely wrong to me
<whitequark>
if you link me some docs I can look through that
<pke>
33.2.1.4 DEVICE PROGRAMMING USING THE ENHANCED JTAG INTERFACE Enhanced JTAG programming uses the standard JTAG interface but utilizes a programming executive written to RAM. Use of the programming executive with the JTAG interface provides a significant improvement in programming speed.
<pke>
i dont know if that part is relevant
<whitequark>
let's see
<whitequark>
meanwhile, can you acquire a dump with -vv ?
<whitequark>
pke: btw, to set your expectations, the jtag-mips applet is quite slow
<whitequark>
it's definitely possible to add some kind of accelerator but i haven't done that yet
<whitequark>
and the architecture of that accelerator would require thought
<whitequark>
pke: wait. waaait.
<whitequark>
oh you set port B voltage to 0 because you're using the bank itself, nvm
<whitequark>
fwiw I can get PIC32-PINGUINO-MICRO with PIC32MX440F256H to test this locally
<pke>
ok i did the modification now i get DR_IDCODE is not defined. So im still missing something. '
<pke>
Bank voltage is set to 0 becuse i removed the port buffer.
Xesxen has joined #glasgow
<whitequark>
add "from ...arch.jtag import *" at the top
<whitequark>
I don't have a system set up right now so I'm working from memory more or less
<pke>
I dont mind the speed, for now i want to test some things out. For those devices JTAG is enabled by default and can be disabled from code not configuration. I want to see how efective it is.
<whitequark>
ah ok
<pke>
I called the tap_interface.write_ir(0x05) without checking for vendor id because it gave me bitarray errors, and for tests whatever. Still asserts out in the same way. I will com back to this issue. But its already late and i need sleep.
<whitequark>
er, sorry, I gave you wrong directions
<whitequark>
0x05 won't work
<pke>
Anyway thanks for the quick help.
<whitequark>
you need to replace that with "10100"
<whitequark>
(a string)
<pke>
That worked.
<pke>
EJTAG version 4.0
<pke>
now dies with ProbTrap/ProbEn stuck low
<whitequark>
oh, *4.0*.
<whitequark>
yeah I've never seen a 4.0 device before
<whitequark>
iirc it needs yet another cursed workaround in JTAG code
<whitequark>
I'll buy a devboard I guess
<pke>
I have the digilent uc32. But jtag is kinda hard to solder onto. But i have other pic32-s around. I will check with them too.
<pke>
Next week i guess.
<pke>
But i`m happy. After a week of nothing, this is good progress
<whitequark>
it is very likely that ProbTrap/ProbEn are stuck low because of some guard bit
<whitequark>
i.e. "debug enable" not set or somesuch
<pke>
Inabled Debug config bit. Same outcome
<pke>
*Enabled
pke has quit [Ping timeout: 256 seconds]
<whitequark>
it could be something in EJTAG 4 that I don't handle
<puck>
whitequark: hmm, so i'm trying to figure out how to modify the NAND applet to work more reliably with other stuff