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.

Topics - AlexS

Pages: [1] 2
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 / 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 / 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


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 / 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.


NXPTM M522XX, KINETIS and i.MX RT / SD Task locking
« on: May 27, 2021, 03:00:48 PM »

Our firmware's architecture involves two FreeRTOS tasks, one running uTasker and the other periodically calling utWriteFile() at a frequency of around 50Hz. What I saw was that the fnMassStorage task would simply lock trying to talk to the SD card, essentially blocking all the other uTasker tasks from running. Unfortunately due to other issues I wasn't able to dig deeper into the problem, but was curious as to whether this has been seen before. We are currently running uTasker with Git commit SHA1: 3c417a7002c9d9840e025bb445208070a62327df


NXPTM M522XX, KINETIS and i.MX RT / Swapping MCUs mid-production
« on: April 14, 2021, 04:14:28 PM »

The MCU we were using, MK66FN2M0VLQ18 is unfortunately hit by the worldwide chip supply shortage and won't be available for another year. So currently trying to asses the feasibility of switching to a similar MCU, while keeping our new firmware compatible with the old MCU (customers can do firmware updates and we don't want to double the number of firmware lines we maintain). The processor I think would work well is the MK26FN2M0VLQ18, as we aren't using any of the extra features on the K66. What changes would be required in the firmware for this switch? As far as I can tell, the clock configuration stays the same and the linker file is identical given that it's also a 2MB and 256KB of RAM device. Anything we're missing?


USB / USB CDC initialization on Kinetis K66
« on: April 06, 2020, 11:02:14 AM »

So we've been running uTasker and USB successfully on our product for quite a while now. Unfortunately, we've had a few USB-related failures where the customer would plug the cable in his laptop and the MCU would just die and take D6 out as well.  Now, as you can probably see, we have an odd setup, there the 5V derived from our main 12V supply is fed into the USB5V line coming from USB through a diode and then going into VREGIN pins and powering the USB transceiver.

The reason we had to do this was to have the USB transceiver powered in order to initialize it at power-up, but I think we've done it wrong. Is there any way in which we can remove D6 and essentially only have VREGIN powered when the USB is plugged in? Detecting the "USB plugged" event and only initializing USB then.


µTasker general / CAN TX Timeout
« on: January 14, 2020, 01:08:08 PM »

Using uTasker (with excellent results) on an automotive project. On the CAN-side of things I'm seeing a peculiar behaviour in a specific corner case. The corner case is one where my device is the only device switched on the CAN bus with another, that should receive my messages, being turned on a few seconds later. What happens is that the TX buffers quickly get filled up, but, oddly, they don't ever timeout, contrary to what's described in the documentation. The documentation suggests that the buffers will be freed after a certain number of retries.

After looking through the code, I noticed that the CAN_TX_BUF_ACTIVE flag is only cleared in case there's no ACK coming, not if the message can't be sent. Page 10 of the uTasker CAN documentation suggests that the expected behaviour is for the buffer to be returned to an inactive state by the driver, informing the application that the message couldn't be delivered.

        if ((ulError & CAN_ACK_ERR) != 0) {                              // a transmission received no ack
            while (i-- != 0) {
                if ((ptrCanQue->ucMode & CAN_TX_BUF_ACTIVE) != 0) {      // this buffer is presently transmitting a message
                    if (++(ptrCanQue->ucErrors) >= MAX_TX_CAN_TRIES) {   // we allow a few attempts before quitting (it also filters counting normal active buffers)
                        ptrMessageBuffer->ulCode_Len_TimeStamp = ((ptrMessageBuffer->ulCode_Len_TimeStamp & ~CAN_CODE_FIELD) | MB_TX_INACTIVE); // stop transmission
                        can_error_int_message[MSG_DESTINATION_TASK] = ptrCanQue->TaskToWake;
                        if ((ptrCanQue->ucMode & CAN_TX_BUF_REMOTE) != 0) {
                            can_error_int_message[MSG_INTERRUPT_EVENT] = CAN_TX_REMOTE_ERROR;
                            ptrCanQue->ucMode = (CAN_TX_BUF | CAN_RX_BUF_FULL | CAN_TX_BUF_REMOTE); // mark that it is an errored transmission buffer
                        else {
                            can_error_int_message[MSG_INTERRUPT_EVENT] = CAN_TX_ERROR;
                            ptrCanQue->ucMode = (CAN_TX_BUF | CAN_RX_BUF_FULL); // mark that it is an errored transmission buffer

utFAT / SD write speed and processor load
« on: January 24, 2019, 04:36:21 PM »

We run a Kinetis K66 with a microSD card slot connected in 4-bit mode. I've done some basic benchmarks this morning with the standard write size we're going to be doing most of the time (1.4KB) and I noticed some that the main iteration time for the main task reduced significantly. It used to be able to run one processing iteration every 1.7ms. After I've added the 1.4KB writes to it, the duration for one iteration increased to 10-35ms. Is there any setting in utFAT that would improve things? The file system I've used when formatting was FAT32 and the default allocation unit size.


NXPTM M522XX, KINETIS and i.MX RT / VBAT Detection
« on: January 04, 2019, 04:40:02 PM »

Unfortunately, when we designed our K66-based board, we didn't expect for the MCU designers to not factor in a way of detecting whether VBAT is present or not, without triggering a bus fault when trying to access the RTC registers. Mark, I've seen one of your posts on the NXP technical community mentioning a way to use DMA to detect whether VBAT/RTC are active or not. Do you have some example code on the subject by any chance or maybe suggest an alternative solution?



I'm wondering, given that the application code rests in Applications/ and the project configuration file is in the root folder, how should individual application files be versioned when using uTasker?


I've read all of the forum threads on how the ADC operates on the Kinetis and also spent some time trying to understand the examples from ADC_Timers.h. For all the value that uTasker provides, I think a slightly more comprehensive document covering ADC operation and individual examples on various types of setups would greatly improve the experience and alleviate the learning curve. :)

With that in mind, let me jump straight in. Our product requires several ADC channels to be running, sampling and converting at the same time, on both AD0 and AD1. I wrote a simple driver to wrap uTasker's ADC functionality with another layer to provide the same interface as the old Processor Expert drivers. I just want to make sure I got the basics right, if someone more familiar doesn't mind taking a look:

1. First of all, this is the routine for calibrating the ADC. It's only done once for both AD0 and AD1 at startup.

Code: [Select]

adc_setup.int_adc_controller = ad;
adc_setup.int_adc_sample = (ADC_SAMPLE_LONG_PLUS_12 | ADC_SAMPLE_AVERAGING_32); // additional sampling clocks
fnConfigureInterrupt((void *)&adc_setup);

As I'm setting everything up with the interrupts disabled, at this stage I should poll for the result and perform the calibration as described in the Kinetis reference manual? Is there any example on how to do this in uTasker?

2. After performing the ADC calibration, I initialize both AD modules in this manner, for continuous sampling and conversion:

Code: [Select]
adc_setup.int_adc_controller = ad;
adc_setup.int_adc_result = (ad == ADC_MODULE_0) ? (&ad0_results) : (&ad1_results);
adc_setup.int_type = ADC_INTERRUPT;                                  // identifier when configuring
adc_setup.int_adc_bit = chan_msk;
| ADC_LOOP_MODE | ADC_ALL_RESULTS  | ADC_START_OPERATION); // single ended configuration in loop mode
adc_setup.int_adc_speed = (ADC_SAMPLING_SPEED(5000000));  // 5MHz sampling (must be between 100kHz and 5MHz)
adc_setup.int_adc_int_type = 0;                                      // no interrupt
fnConfigureInterrupt((void *) &adc_setup);                            // configure and start operation

Then, approximately each 2ms, I read the result values and statuses from the corresponding variables (ad0_results or ad1_results)

Code: [Select]

switch (module) {
case ADC_MODULE_0:
res.ucADC_status = ad0_results.ucADC_status[chan_idx];
res.sADC_value = ad0_results.sADC_value[chan_idx];
case ADC_MODULE_1:
res.ucADC_status = ad1_results.ucADC_status[chan_idx];
res.sADC_value = ad1_results.sADC_value[chan_idx];



Is manually accessing the FTM_CNT register the only option to get the current value of an FTM counter?



As I have mentioned before, I'm currently working on porting a project based on Processor Expert and Code Warrior, running on a K22 to uTasker. In the PE project, the storage solution chosen was based on a basic storage system written from scratch that ran on top of PE's drivers for the MCU's internal flash. It worked (and still does) great. Before I ask my question, I'll briefly describe the storage mechanism:

1. Data that I need to store is essentially a collection of entities, serialized at different sizes, each uniquely identified through an ID.
2. On device power-up, the storage routines would try and load a basic storage system control structure from a predefined address in flash. That control structure would contain a set of entries, each offering a data entity id, offset in flash  and size of the stored data.
3. For each of the data entities, it would go at the specified offset, load the specified entity, check its integrity and deserialize it.
4. During the normal operation of the device, those entities might be modified externally, operation which would trigger the storage system to erase and then update that entity's flash serialized version.

My first instinct was to use the low-level flash routines. One downside is that I'll need to add a driver on top of that to backup the other data in the sector(s) to be erased. Not a big problem, but that got me thinking if it wouldn't be better to use the built-in file system for added functionality down the line.



Pages: [1] 2