µTasker Forum > USB

Transition from HS to FS USB

(1/2) > >>

AlexS:
Hi everyone,

We've been forced by the chip shortage to move from our MK66FN2M0 chip with HS USB to a MK24FN1M0 that only has FS USB. While initial very basic testing looked good (after some advice from Mark), we've hit some serious stability issues. Essentially our app involves sending ~850 bytes at 10Hz to the PC, which should be more than enough for the 12Mbps of FS USB, but we're seeing serious stability issues. I've captured a log of such an instance, opens with USBlyzer, a USB sniffing tool.  (https://www.usblyzer.com/download.htm).

I also took a screenshot of when the issue occurs in the log. The odd thing is that this seems to be PC-related. A faster PC is much more unlikely to generate the problem, while slower PCs trigger it almost immediately.  The faster PCs are able to keep a stable connection for minutes at an end. I'll be doing further troubleshooting tomorrow, as I'll connect some debug pins and try to see whereabouts in the USB flow the problem appears, but any tips would be greatly appreciated. As with most development projects, this is also running late :)

Thank you!

mark:
Hi Alex
Could you post a reference where is is working since at the moment i don't understand what the log is showing and what the error actually is.
There is something about an unsuccessful stall PID in an IN bulk or interrupt transfer, but I don't see any details about what endpoints are being used.
Also, is it possible to see the enumeration too so that the device details are known?
Regards
Mark

AlexS:
Hi,

Thanks for the reply. Things got a little heated close to our northern border, so hoping to get this sorted relatively quickly. I've attached full device information as seen by the USB sniffer. After investigating further, the device simply enters the defined hard fault handler after a random time of USB exchanges. The hard fault is always forced and the fault is either "Undefined Instruction", "Access Violation" or similar. The stack seems healthy, but I'm working on narrowing down potential causes

AlexS:
Managed to narrow it down to a bus fault error that always happens on these lines. That address that's loaded into R2 is totally bogus and what's triggering the bus fault error.

AlexS:
Did a bit more investigating tonight, but there's a behavior that is really impossible for me to explain. Please take a minute to look at the pictures I've attached and follow my rationale below. It might be that, after about 40hrs of debugging this, I'm missing something really obvious.

1. First of all, please look at 'fault.png'. The relevant registers say that the error address is valid and that the BusFault was caused by a load from address 0x0040 0008.
2. Now in 'main.png'. The callstack suggests that the instruction that caused the fault is at at 0x9340 (below the red line in the disassembly window). This looks plausible as the current value in R2 (left side pane) is indeed 0x0040 0000 and, with an offset of 8, gives us exactly the address in BFAR.
3. But how can R2 have 0x0040 0000 in it when, just in the previous instruction, at PC 0x933E, its value is loaded from the address stored in R7, with a 0 bytes offset.
4. Looking at the value in R7, R2 should actually have 0x2000 FF48, which is what the memory view shows us.

So how is it possible that between two instructions in the USB memory handler, only the value of a single register (R2) gets changed.

PS: When I manually stepped through the function in a working instance, that 0x0040 0000 was actually the result of the operation above (ANDS R3, R2). It's almost like the underlined instruction was never executed.

Navigation

[0] Message Index

[#] Next page