CMSIS-DAP intermittent errors during initialization in IAR.

[alexian79]

Hi, first, thanks for the great project, just received my new orbtrace-mini with M7 mule.

Trying to use probe in IAR, with different drivers, GDB(different backends: PyOCD, OpenOCD) and CMSYS-DAP. At first I was not successful with CMSYS-DAP, but later was able to make it work with poking some settings. After some trial and error It looks like it mostly worked with 2Mhz clock. It does not work with autodetect. I think One time it worked at 30Mhz!!!

I have an impression if it connected at 2Mhz you can increase clock higher next time. but not wise versa. I have attached some logs of communication for CMSIS-DAP driver. Maybe you can spot something important there. It will be nice to make this HW flawless:)

cspycomm_success_with_download_2Mhz.log cspycomm_success_with_some_errors.log cspycomm_failed_at_autodetect.log cspycomm_success_connect_at_2MHz.log cspycomm_failed_with_enabled_flash_load.log

[alexian79]

I did play with idle cycles and COOLING state in general. And increasing MIN_IDLE_CYCLES=16 worked in my case. Also tried to increase that hardcoded 2 as well. But what I have noticed on the scope: it looks like that idle cycles value is applied after we encounter wait response, I still don't see extra idle cycles at the end of the transfer. and what I think is happening - I am being lucky I captured 2 transfers in a row and I see that at start of second transfer I can see wait response, so it means that internally access is not finished yet, and it most likely will be canceled if it will be that DP status read. So it probably happen again with transfer that will trigger wait for the next access.

here is last transfer in first block and here is start of another block

Looks like IAR approach to send DP 1 is a bit unreliable unless we somehow can clock in transaction at the end of the previous transfer. I am very curious to see what I-Jet transfer will look like, it is working up to 66Mhz, unfortunately it is not very easy to capture.

Question: will it work if I plug I-jet into dbg 10 pin connector on the orbtrace and use 20 pin to the target as it is now? and do capture scope from the side pins? Thanks.

As always scope data attached. scope.zip

[zyp]

Question: will it work if I plug I-jet into dbg 10 pin connector on the orbtrace and use 20 pin to the target as it is now? and do capture scope from the side pins? Thanks.

Currently the application gateware always have the output buffers for TCK and TDI enabled, and so would conflict with them being driven externally, but if you boot the orbtrace into bootloader mode, all the target signals should be tristated allowing you to use it as a passthrough.

[alexian79]

Great tip, thanks

[alexian79]

Sadly I am not able to power my mule from USB connector, for some reason 5V does not pass after diode. But I did capture handheld during target running. One thing looks like a cheat, at start of periodic sequence of multiple transactions probe clocks the line for some amount of time, hmmm attaching scope data. scope.zip

[alexian79]

Ok, got some mixed feedback from IAR, they said that changing WaitRetry value is not supported, luckily it looks like that was not a problem. Good news they support V2, but for some reason they do not switch to it, requested some help on that from their side.

[alexian79]

I tried to compare orbtrace vs rpi probe detection in IAR, looks like RPI is connected as V2, maybe it does not support V1, not sure yet but that is a good sign for me. Maybe will try to disable v1 support in orbtrace and see what happens.

[mubes]

OT supports both v1 and v2 but I guess once it's found one it doesn't look for the other. That's sensible but I would have expected it to try for v2 first :-)

I still need to fix your info length violations in case that is upsetting something. Will try and do that today.

On Tue, 1 Aug 2023, 04:43 Oleksiy Bondarenko, @.***> wrote:

I tried to compare orbtrace vs rpi probe detection in IAR, looks like RPI is connected as V2, maybe it does not support V1, not sure yet but that is a good sign for me. Maybe will try to disable v1 support in orbtrace and see what happens. [image: image] https://user-images.githubusercontent.com/1855089/257399632-4864428f-5d8a-43b6-bf9d-919e8809d2d6.png

— Reply to this email directly, view it on GitHub https://github.com/orbcode/orbtrace/issues/18#issuecomment-1659518149, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJTBDZGK5WAEMWZMZWPDR3XTB3OTANCNFSM6AAAAAA2CPDQQ4 . You are receiving this because you commented.Message ID: @.***>

[alexian79]

I think it is more complicated, if I disable v1 in device drivers it does not proceed to v2, but I will experiment further, and find out. PS. Good news for me I was able to fix my beagle USB sniffer!!! my investment in thermal camera couple year ago finally paid off, it was tiny capacitor that shorted to ground. Officially nothing was damaged during this debug effort :)

[alexian79]

As a first step I have tried to build gateware with self.add_cmsis_dap(with_v1=False) and had unexpected result, instead of hid device disappearing I have got 2 version 2 interfaces. Is this expected behavior?

normal situation with his is below.

As a next step, I would like to have only one dap and move it's interface to 0. as I see for RPI probe.

[zyp]

This is likely Windows partially caching the device metadata, so it remembers you had a v2 interface on MI_05, and now it also sees you have a v2 interface on MI_04. For new releases we're triggering a flush of the cache by increasing the bcdDevice field in the device descriptor, but that's derived from the most recent git tag so it doesn't change until you tag a new version.

[alexian79]

Good point, I will be deleting devices after shifting interfaces. I am looking in to wire shark logs trying to understand how it enumerates devices. It looks like as a first step it gets string with the name. Will continue on that.

[alexian79]

so far no luck yet, Moved CMSIS-DAP v2 descriptor first, but IAR ignores it :(,

[alexian79]

Have got reply from IAR, they have voiced interest in ordering orbtrace. But I will continue experimenting to try make it work as is.

[alexian79]

I think, one of the ways IAR looking for probes is by GUID, I found this guids used in one of the dlls that probe for USB devices and looks like they are matching with guids mentioned here for CMSIS-DAP v2 https://arm-software.github.io/CMSIS_5/DAP/html/group__DAP__ConfigUSB__gr.html I could not find those exact matches in microsoft_wcid module, and find it easier to ask:), are those added somewhere to device descriptors for orbtrace? I checked source for rpi probe and those are added https://github.com/raspberrypi/picoprobe/blob/master/src/usb_descriptors.c

[zyp]

Oh, good find, I weren't aware that the reference CMSIS-DAP implementation defines GUIDs we could reuse, nor that anybody would be filtering by those. We've got custom GUIDs on our CMSIS-DAP interfaces.

I don't think there would be any downside for us to switch to the reference GUID, so we might as well do that. @Novakov what do you think?

[alexian79]

Great, at least you can do custom build type or parameter to orbtrace_builder, is it DEVICE_INTERFACE_GUID_BASE that needs to be changed? I can try it

[zyp]

Currently the way the GUID mechanism works is that since each WinUSB interface needs its own GUID, we're using a common base that we're only inserting guid_discriminator into. The right way to solve this would probably be to add the ability to pass in a full GUID instead of a discriminator, and utilize that for the CMSIS-DAP v2 interface. The rest of the interfaces should keep their current GUIDs.

[alexian79]

Ok, got it. Just for the sake of debugging I will try to hardcode something up.

Maybe it make sense to discriminate that parameter by type, you can pass short guid_discriminator or full UUID instance, at least easy to try

[alexian79]

Yoo-hoo, it detects both interfaces now!

[zyp]

Hi, I added the reference GUID to the v2 interface in 364ad85, which just went into the 1.4.0 release. I would appreciate if you could confirm that detection in IAR is now working.

[alexian79]

Hi, I confirm that detection in IAR works now! thank you, I was running my custom build up until now. Will test more.

[zyp]

That's great. Are you still seeing any of the original issues you were having earlier in this thread, before we got sidetracked with the v2 support?

[alexian79]

At the moment v 1.4.0 works at 20Mhz. Which is ok.

[zyp]

In that case I'm gonna go ahead and close this issue.

[mubes]

Do you see issues at 25MHz, or is that beyond the rest of your setup? I think 20MHz will be actually running at 16.6Mhz which, to be fair, is still quite fast enough (we see diminishing returns beyond 10MHz...the chips just return more WAITS, so things don't really get much faster) but it would be nice to know where the max limits are.

Dave

On Fri, 6 Sept 2024, 00:12 Oleksiy Bondarenko, @.***> wrote:

At the moment v 1.4.0 works at 20Mhz. Which is ok.

— Reply to this email directly, view it on GitHub https://github.com/orbcode/orbtrace/issues/18#issuecomment-2332848351, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJTBD4J3R7N7O2O7V4E37DZVDQMVAVCNFSM6AAAAABNXJXEB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZSHA2DQMZVGE . You are receiving this because you commented.Message ID: @.***>

[alexian79]

Hi, I think with some tweaks I was able to make it work at 25Mhz in my custom FW, but I agree with your explanations that this is not critical for me now. As long as SWO works fast:). I have new board with stm32N6 chip that is M55 with hi clock. will be interesting to see how fast it can go. it has trace connector onboard.