05:41 <zapb_> PaulFertser, thanks!

08:19 <Hammdist> are 2x7 JTAG cable connectors in any way keyed for polarity?

08:19 <Hammdist> that is, it seems not so to me if I were to just put a 2x7 grid of square pins on the pcb, nothing would prevent it being connected the wrong way around

08:32 <jeanthomas> Hammdist: I often see boards with keyed IDC connectors instead of simple headers

08:34 <Guest98> HI all,

08:34 <Guest98> Is it possible to ask here and get some help regarding OpenOCD setup for RiscV CPU. What I am using is RTL simulation via JTAG and on TB side I have JTAG VPI instantiated in UVM environment.

08:34 <Guest98> Now I am facing some issues and help would be good in case someone has experience in that ?

08:34 <Guest98> Thanks,

09:31 <PaulFertser> Guest98: hey. It's ok to ask here but probably your question is a rather hard one. What exactly is the issue you see?

09:33 <PaulFertser> Hammdist: https://documentation-service.arm.com/static/5fce6c49e167456a35b36af1 looks keyed to me

09:40 <PaulFertser> Hammdist: 2x7 sounds like EJTAG so it must be MIPS you're working with?

09:40 <PaulFertser> Hammdist: square pins means SMT but SMT IDC sockets are keyed too.

09:42 <PaulFertser> I misread pins for pads because I thought you're talking about PCB itself. So not necessarily SMT.

09:43 <PaulFertser> Reverse connection polarity is safe with a reasonable JTAG adapter anyway.

14:06 <JoseT> Hi, I have an issue in getting device halted with TI CC2340R5. I am using VS Code and OpenoCD.

14:06 <JoseT> Run to Main works fine, device get halted in main. But after run is issued from main, device is not getting halted. I am seeing the below error message,

14:06 <JoseT> Info : [cc2340r5.cpu] external reset detected

14:06 <JoseT> Info : The target is not running when halt was requested, stopping GDB.

14:06 <JoseT> Error: [cc2340r5.cpu] not halted (gdb fileio)

14:06 <JoseT> I tried to print the target state and I can see that OpenOCD is assuming target is in TARGET_RESET state. But from led blinking its clear that fw is running. Checking further showed that RESET,RETIRE bits in dhcsr register is set.

14:06 <JoseT> Info : cortex_m->dcb_dhcsr_cumulated_sticky 0x3070003, cortex_m->dcb_dhcsr 0x3040001

14:06 <JoseT> However, no reset has actually happened.

14:06 <JoseT> I would highly appreciate if anyone can explain whats happening or directions on how to resolve this.

14:06 <JoseT> Thanks in advance.

14:20 <Haohmaru> JoseT, what debugger are you using?

14:22 <Haohmaru> could it be that your debugger is not actually seeing the RESET signal

14:33 <JoseT> I am using XDS110. You mean RESET from device?

14:36 <Haohmaru> no idea what that is, but typically i think the debugger/openocd wants to see/control the RESET

14:36 <Haohmaru> at least in my experience ;P~

14:36 <Haohmaru> to say it another way, are your connections "proper" ;P~

14:38 <JoseT> Issue is not happening with all firmwares. Unfortunately I cant figure out exact difference between firmwares, but could be related to sleep. Some firmwares are working absolutely fine.

14:39 <JoseT> My connections are proper as far as I checked

14:48 <Haohmaru> ah, so you're doing the same thing on multiple "same" devices, and this only happens on some of them?

14:53 <JoseT> Not multiple devices. Single device, proble with some firmwares

14:54 <Haohmaru> can a firmware disable some debugging-related things like RESET or what not

14:54 <Haohmaru> but you probably wanna wait for someone more familiar with that stuff than me

14:55 <PaulFertser> JoseT: I'd step through main to see what exactly makes it behave like that.

14:55 <PaulFertser> JoseT: guess it's some internal hardware getting reconfigured in a way that's confusing.

14:56 <PaulFertser> JoseT: also I can imagine it getting reset and then run and if you judge just by the blink you can not know if it was reset or not.

15:33 <JoseT> Yes that make sense. so you are suspecting likely there is a reset happening internally which is making debugger loose connection ? I can check that. My dissassembly is also not getting loaded, I dont have source code but i can try to get that.

15:38 <JoseT> PaulFertser, I will be able to continue tomorrow and give an update. thanks