Orbtrace doesn't work correctly for me about orbuculum

[TomKeddie]

@Benjoyo from the doco it looks like you can set the speed of the trace port on the nrf52840 in the same way you can on the nrf52832 you should try my script.

[mubes]

Hi Bennet, Any chace.you can join join the orbuculum discord channel in about an hour and we can chat about this interactively? The heartbeat led will flash while the FPGA is loaded. When the device is synced you should get the sync led on too. Overflow will illuminate when there are more packets from the target than can be transferred over the link. The code currently in there for the interface is a slight hack. The spi interface on the ftdi chip is much faster than the uart, so we transfer collections of 900 sample packets and mark them as being empty or full (i.e. containing data). What you are seeing indicates that there is no data in the packets, which is consistent with sync not being illuminated. What voltage is the nrf running at? If it's 1v8 chances are it's not registering a logic high.... Regards Dave

…

On Fri, 11 Dec 2020, 16:55 Bennet, ***@***.***> wrote: I am trying out orbtrace with an iCE40HX-8K Breakout Board. Building and flashing worked and orbuculum seems to talk to the FPGA fine as well. First issue that arised was: Orbuculum V1.10 (Git 0146E353 Dirty, Built 2020-11-30 12:40:35+0000) BasePath : ForceSync : true Permafile : false Orbtrace : 4 bits width Using TPIU : true (ITM on channel 1) Channels : 00 [info] [info] HW [Predefined] [hwevent] Port opened All parameters configured orbuculum: Src/nwclient.c:221: nwclientSend: Assertion `len' failed. Aborted That was quickly fixed by recompiling with WITH_NWCLIENT=0, since I don't need it. But you may want to check that out (maybe it is related to the root problem below). Now I get: orbuculum -o 4 -c 0,info,"%c" -v 3 Orbuculum V1.10 (Git 0146E353 Dirty, Built 2020-12-10 12:54:20+0000) BasePath : ForceSync : true Permafile : false Orbtrace : 4 bits width Using TPIU : true (ITM on channel 1) Channels : 00 [info] [info] HW [Predefined] [hwevent] Port opened All parameters configured RXED frame of 0/900 full packets ( 0%) RXED frame of 0/900 full packets ( 0%) RXED frame of 0/900 full packets ( 0%) RXED frame of 0/900 full packets ( 0%) RXED frame of 0/900 full packets ( 0%) ... Heartbeat is blinking. Same thing with only 1 bit width. I am not sure what this output means. Can it be that I am just stupid and didn't wire it correctly? Do I need to configure something special in the code or gdb, besides enabling ITM and TRCENA? I am using a NRF52840 Preview DK. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#45>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJTBD7C6ORZLNS6WSOOGIDSUJFJJANCNFSM4UW5KW3A> .

[Benjoyo]

Hey Dave,

sorry I didn't read your reply soon enough (I guess we have some time shift between us).

I power the board via USB, so as expected the regulator regulates that down to roughly 3v (2.98 measured between VDD and GND).

Should I just continue to write in discord even though we might not really be online at the same time? I assume this is not a bug but just me being stupid and needing some support.

Thanks,
Bennet

[mubes]

Hi, I'm in GMT but should be on discord this evening....we can 'chat' either there or here but you're likely to make progress more quickly over there. The FPGA stuff should be viewed as pretty experimental, but it certainly is working. Are you sure you've got data coming out of the trace pins on your device? It's always a good idea to go through the obvious things before starting on the hairy ones, although given the maturity of that code it's more likely a problem amongst the hairy stuff. Dave

…

On Sat, 12 Dec 2020, 10:26 Bennet, ***@***.***> wrote: Hey Dave, sorry I didn't read your reply soon enough (I guess we have some time shift between us). I power the board via USB, so as expected the regulator regulates that down to roughly 3v (2.98 measured between VDD and GND). Should I just continue to write in discord even though we might not really be online at the same time? I assume this is not bug but just me being stupid and needing some support. Thanks, Bennet — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#45 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJTBD22TEAFEGV3BGZF6B3SUNANDANCNFSM4UW5KW3A> .

[Benjoyo]

Ok, so not much time shift after all (I'm in Germany).

I am not certain that the trace pins work (is there an easy way to check?). I use your gdb scripts to init stuff like ITM and DWT and additionally I compile with ENABLE_TRACE, which should result in the trace pins being used for trace and not GPIO.

I'll try to join the discord tomorrow or monday when I got the time.

Thanks,
Bennet

[mubes]

If you've got a scope check the traceclock pin...it should have a regular square wave on it. Frequency is determined by the setup for your chip but generally it's the main clock divided by two. Assuming you're using 4 bit trace then trace0,1&2 will be mostly high, trace3 will go low at intervals (it's transmitting fff7). When Orbtrace sees those syncs then it'll illuminate the sync led. You will certainly have to do things to enable the trace pins on your platform...it's possible that's just the stuff you've already done, but I don't honestly know. Once it's figured out we can add it into the gdbtrace.init file. Regards Dave

…

On Sat, 12 Dec 2020, 16:39 Bennet, ***@***.***> wrote: Ok, so not much time shift after all (I'm in Germany). I am not certain that the trace pins work (is there an easy way to check?). I use your gdb scripts to init stuff like ITM and DWT and additionally I compile with ENABLE_TRACE, which should result in the trace pins being used for trace and not GPIO. I'll try to join the discord tomorrow or monday when I got the time. Thanks, Bennet — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#45 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJTBD6UBX7S5ZZUJDERZ4LSUOMDDANCNFSM4UW5KW3A> .

[Benjoyo]

Thanks, I will investigate and report back.

Bennet

[Benjoyo]

@mubes I got a step further. I don't know why I didn't do this right away, but I now basically do what _doTRACE does in your gdb init file plus I define ENABLE_TRACE, which takes care of configuring the GPIOs and setting TRACEMUX to parallel trace.
Now that I did that, I finally get some activity on all 4 trace pins and the clock pin. Before only one trace pin and the clock was active.
However, I still get the same output from orbuculum :/

[mubes]

OK, please take a look at 07c4dc0 ... that should simplify your woes quite a bit.

[mubes]

OK, I beleive this is fully resolved in 17c2b0c although you might still have to do a small amount of work (e.g. on the pin configuration in gdbtrace.init) to adapt it to your specific chip. Let us know how you get on and please send any config patches that are needed.

[mubes]

@Benjoyo I think this is just pending on you getting a good gdb config together for your specific chip now, so I've removed the WIP marking. Please keep us posted so I can close this down when it's verified resolved.
DAVE

[mubes]

Killing this after radio silence for a month. It's believed fixed.