Recent Posts

Pages: 1 ... 8 9 [10]
USB / Re: USB CDC initialization on Kinetis K66
« Last post by mark on April 06, 2020, 03:43:43 PM »
Hi Alex

The VREG is used for the USB transceiver (as you know) ad can also be used to supply 3V3 to other parts of the circuit, or eve the processor itself in a USB power supplied circuit.

If only used for the USB transceiver the VREGIN can be connected to the USB host's 5V line so that it is supplied only when the USB is connected - it doesn't need to be detected and initialised only when connected since USB can otherwise initialised earlier
- this is certainly the case for FS USB device
- in case you use the HS device on the K66 the PHY's PLL will possibly not lock when the supply is not connected, this stopping the initialision from working

In the second case it may indeed be necessary to monitor the power supply to ensure that it can start.
Another option may be to detect that the PLL can't lock and abort initialisation, afterwards using the PLL lock interrupt (assuming one exists) as detection indication and allowing the initialision to continue/repeat.

I don't understand the HW issue of leaving VREG supplied all the time since this is also what some of the reference designs do but if it needs to be avoided I believe the the PLL control is what is needed to control the operation, but I haven't actually a method to manage this at the moment.


USB / USB CDC initialization on Kinetis K66
« Last post by AlexS 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.

NXPTM M522XX, KINETIS and i.MX RT / Re: USB Serial Port Driver Problem for Windows 10
« Last post by Phil on March 24, 2020, 10:04:44 PM »
Problem resolved.

Apparently, I had an interference issue with another piece of software. I shut down all pieces of software (KDS, Segger JLink, etc.) and was about to restart by PC when I noticed the USB was connecting without an error (simple beep). Once I removed the RS232 port, I was able to connect via USB-CDC virtual COM port as expected. Weird!

Thank you anyway.

NXPTM M522XX, KINETIS and i.MX RT / Re: USB Serial Port Driver Problem for Windows 10
« Last post by Phil on March 24, 2020, 08:21:30 PM »

I have another of these situations with a KL27 MCU. The MCU connected to a Windows 10 machine shows a "USB device not recognized".  On this device, I am using the setting USB_CRYSTAL_LESS setting to use the internal 48kHz clock.

#elif defined MY_KL27Z_BOARD
    #define RUN_FROM_HIRC                                                // clock from internal 48MHz RC clock
    #define BUS_CLOCK_DIVIDE     2                                       // bus and flash clock divider value (1..8)
    #define USB_CRYSTAL_LESS                                             // use 48MHz IRC as USB source (according to Freescale AN4905 - only possible in device mode) - rather than external pin

I did modify the "product_str[]" descriptor name. I am also using Kinetis' PID/VID designation.

Finally, I am using both USB-CDC and the DEMO_UART port.

Any suggestions?


NXPTM M522XX, KINETIS and i.MX RT / Re: Bootloader by SD card for the RT1020
« Last post by mark on March 13, 2020, 09:23:40 AM »
The SD card loader for i.MX RT 1020 is ready and can be tried at


NXPTM M522XX, KINETIS and i.MX RT / Re: Bootloader by SD card for the RT1020
« Last post by mark on March 11, 2020, 05:05:31 AM »
utFAT has been ported to the i.MX RT 1020 - binary available at:

This means that it should theoretically be operational for boot loader use so a version looks good still for this week!



NXPTM M522XX, KINETIS and i.MX RT / Re: Bootloader for Kinetis and interrupts problem
« Last post by mark on March 10, 2020, 01:50:51 PM »

Check Appendix B of the serial loader document for a check-list for compatibility:

When the loader starts the application it performs:
uDisable_Interrupt();                                        // ensure interrupts are disabled when jumping to the application
RESET_PERIPHERALS();                                         // reset peripherals and disable interrupts ready for jumping to the application
start_application(_UTASKER_APP_START_);                      // jump to the application

The macro RESET_PERIPERALS() ensures that any possible pending interrupts are cleared but you can check to see whether it may need to do something more to ensure your application isn't disturbed by previous peripheral usage.


NXPTM M522XX, KINETIS and i.MX RT / Bootloader for Kinetis and interrupts problem
« Last post by LuisHS on March 10, 2020, 10:52:05 AM »
Hello Mark.

I have a problem using the bootloader by SD card. My program works perfectly if I burn it directly to the microcontroller, a Kinetis MK66, using a Jlink.

But if I load it using the bootloader, the start of the program, that turns on/off several LEDs of a LED matrix works perfectly, so I know that the program has been loaded and is running. But what runs next in the program does not work, several GPIOs activated by interrupts must be read.

Is there anything to consider using the uTasker SD bootloader, if the program to be loaded uses interrupts?.  I tried to compile my program generating Debug and Release versions, with optimization disabled, program start address always 0x8000.
NXPTM M522XX, KINETIS and i.MX RT / Re: Bootloader by SD card for the RT1020
« Last post by mark on March 09, 2020, 05:41:32 PM »

There are two possibilities for encryption:
1. The image is AES256 encrypted (on the SD card and copied in the same format to QSPI). It is then decrypted at boot time to run (in unencrypted form) in SRAM.
2. The image is encrypted to run from QSPI flash using the XiP and Bus Encryption Engine (BEE). It is saved in this format to the SD card and is copied in this format to the QSPI flash.

The method used by the uTasker project is generally method 1 (has priority during development) since it allows faster code operation, lower power consumption and lower radiation.


NXPTM M522XX, KINETIS and i.MX RT / Re: Bootloader by SD card for the RT1020
« Last post by LuisHS on March 09, 2020, 03:57:27 PM »
Thanks, I look forward to the version for RT1020 that allows the encrypted bootloader from SD to QSPI.

A question about copy protection:
When the bootloader loads the firmware from SD to QSPI, will the firmware in the QSPI be encrypted?

I have not started working on firmware files signed with the RT1020 yet, but I understand that once the program has been compiled, it can be encrypted before recording it to the boot device (SD, QSPI, hyperflash). Then, in the case of your booloader, in addition to the firmware being encrypted in the SD, once it is loaded into the QSPI from the SD, will it also be encrypted in the QSPI?
Pages: 1 ... 8 9 [10]