Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - AlexS

Pages: [1] 2 3 4
USB / Re: Transition from HS to FS USB
« on: March 11, 2022, 07:46:15 PM »
In order to have some sort of conclusion on this. After reducing the Kinetis flash clock to 20MHz (from 24Mhz, confirmed using an oscilloscope), the hard fault disappeared. After further investigation into another issue (noisy ADC readings) we believe the problem is actually the design of the chip's power supply lines. Instead of a 3V3 plane with decoupling capacitors close to the pins themselves, our design has a single trace running from all the 5 supply pins to the outside of the chip and then the decoupling capacitors are all placed in parallel there.

We're currently doing another design iteration to confirm that was indeed the problem. Will update this post when that happens. Thanks for your help!

USB / Re: Transition from HS to FS USB
« on: March 01, 2022, 01:33:04 PM »
Quick update: it seems that it wasn't the core clock influencing the hard fault occurrence, but actually the flash clock.

Anecdotally, after a few tests:
1. Core clock 96MHz, flash clock 24MHz -> getting faults as often as before
2. Core clock 120MHz, flash clock at 20MHz -> not getting the faults

USB / Re: Transition from HS to FS USB
« on: March 01, 2022, 12:23:44 PM »
Hi Mark,

Thanks for your reply! Have managed to make some progress, but said progress just muddied the waters in terms of what's causing this.

I'll outline below what I have done to debug this and the results:
1. Initially I disabled all instruction and data caching and prefetching. This move has totally eliminated the hard fault occurring in the fnUSB_handle_frame() function and only left me with hard faults that are shown to originate in the prvPortStartFirstTask() function (I've added a picture)
2. Then, when I reduced the clock multiplier from 30 to 24 (essentially lowering the core frequency from 120MHz to 96), all problems essentially disappeared. Which is very odd considering the fact that the USB clock is derived from the internal 48Mhz reference, not from external sources.
3. I then enabled back instruction and data caching and prefetching, got back some of the performance I lost, but the system stayed stable.

As you can see, it's a very odd sequence of events. I can't see how reducing the core speed would get rid of all the issues, unless the system was overclocked to start with.

LE: uDisableInterrupt() (have removed what the precompiler leaves out)

extern void uDisable_Interrupt(void)
    __disable_interrupt();                                               // disable interrupts to core
    iInterruptLevel++;                                                   // monitor the level of disable nesting

USB / Re: Transition from HS to FS USB
« on: February 27, 2022, 12:44:39 AM »
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.

USB / Re: Transition from HS to FS USB
« on: February 24, 2022, 06:12:31 PM »
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.

USB / Re: Transition from HS to FS USB
« on: February 24, 2022, 12:02:34 PM »

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

USB / Transition from HS to FS USB
« on: February 23, 2022, 10:33:50 PM »
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.  (

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!

USB / Re: USB when moving from MK66 to MK24
« on: February 23, 2022, 10:26:05 PM »
Thank you, Mark! That worked, but as we are doing stress testing before moving over to the new processor, we're seeing some very weird USB behavior. Will create a new thread to not mix this up.

USB / USB when moving from MK66 to MK24
« on: February 02, 2022, 12:18:30 PM »

We've switched recently from the MK66FN2M0VLQ18 to MK24FN1M0VDC12 and everything seems to be working, except USB. The first set of prototypes had the pinouts done wrong, but the second design looks ok.  I've attached both the working previous design and the new one.

With the same USB code as before (no configurations changed), the device is correctly recognized by Windows, but getting this error: "The device cannot start (Code 10. An invalid parameter was passed to a service or function.)"

One thing that piqued my interest is that we were using USB1 before, but USB0 now. However I can't seem to find where the USB peripheral ID is configured.


NXPTM M522XX, KINETIS and i.MX RT / Re: CAN Interfaces on K24
« on: November 29, 2021, 10:23:07 AM »
That was indeed the problem, found it when the app first started and noticed that my stack was being placed near the start of my DATA section. Thank you!

NXPTM M522XX, KINETIS and i.MX RT / CAN Interfaces on K24
« on: November 23, 2021, 11:16:01 AM »

Switching MCUs because of the shortage and replaced the MK26FN2M0VLQ18 with the MK24FN1M0VDC12. Our product needs to use the CAN interface on the MCU, but the kinetis.h conditional compile defaults to 0 CAN interfaces for the K24. I'll hack the solution for the time being, but just wanted to make sure I'm not missing anything.

Code: [Select]
#elif defined KINETIS_K24


Thanks for the quick reply Mark! Will get it tested today.

NXPTM M522XX, KINETIS and i.MX RT / Potential CAN error handling problem
« on: October 14, 2021, 11:40:28 AM »
Hi Mark,

While diagnosing a hard fault triggered by CAN operation, I noticed something which doesn't look right. Essentially 'ptrMessageBuffer' ends up pointing to a region of memory which is not in the FlexCAN peripheral (0x4002 4180)

NXPTM M522XX, KINETIS and i.MX RT / Re: SD Card Format Speed
« on: July 13, 2021, 07:21:52 PM »
1. It takes about 8ms per run of fnMassStorage() task with 4ms in between iterations. This is how I'm starting the format:
Code: [Select]
2. Is there any specific routines that must be called after the format completes?  I'm calling utAllocateDirectory() after detecting that the disk is mounted again and getting '0' returned.


NXPTM M522XX, KINETIS and i.MX RT / SD Card Format Speed
« on: July 13, 2021, 06:47:49 PM »

Currently implementing the format function in the product, initial tests show ~6 minutes for formatting an 8GB card. Are there any tips to make it faster? I notice that the fnMassStorage() task is running for around 7ms each iteration.


Pages: [1] 2 3 4