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 - Phil

Pages: 1 [2] 3 4
16
NXPTM M522XX, KINETIS and i.MX RT / KL27 ROM Bootloader with KDS
« on: June 16, 2020, 12:00:23 AM »
Mark, et al,

I am writing firmware for a KL27 with embedded ROM bootloader using KDS.

When writing directly directly into the KL27 using my SEGGER JLINK I using the build configuration uTaskerV1.4_FLASH. Everything works fine.

When using the ROM bootloader, I would think the build configuration changes to uTaskerV1.4_BM_FLASH. When I try to use the ROM bootloader with the newly created BM_FLASH image everything seems to load fine but the KL27 goes into a watchdog-type reset loop upon startup.

Again, when I load using the uTasker1.4_FLASH build configuration using my SEGGER JLINK debugger everything works fine.

Any ideas?

Thanks.

Phil

17
NXPTM M522XX, KINETIS and i.MX RT / Re: USB Serial Port Driver Problem for Windows 10
« 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.

Phil

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

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?

Regards,

Phil

19
NXPTM M522XX, KINETIS and i.MX RT / Re: USB Serial Port Driver Problem for Windows 10
« on: February 26, 2020, 09:07:43 PM »
Mark,

I have not tried to use other products of ours. The customer only has this one unit of ours. We can certainly send him another unit, if that is our best option at this point.

Regards,

Phil

20
NXPTM M522XX, KINETIS and i.MX RT / USB Serial Port Driver Problem for Windows 10
« on: February 26, 2020, 08:25:01 PM »
Mark,

Having troubles with a Windows 10 64-bit user that can't seem to see my uTasker/K64F USB Serial port. When connecting the our uTasker system, the user sees a unknown USB device error message. Going to the Device Manager, Ports (COM & LPT) there is no new COM ports.

Per, https://www.utasker.com/forum/index.php?topic=1960.msg7259#msg7259, and the USB Users Guide, I had him install "uTaskerFreescaleMultiVirtualCOM1-6_64bit.inf" but nothing really changed.

I have had some minor success by unloading the USB Composite Device from the Universal Serial Bus controllers section of the Device Manager. When I reconnect the USB between his PC and my system it loads up with an error about an unknown USB device but it then continues with a recognition of the USB device (I know this because it says my product name "Avolana"). However, it still will not load the USB Serial Port drivers.

Interestingly, I used the bootloader and this same device and I was able to drag and drop a new version of the firmware so I know it is seeing the USB-MSD drivers correctly.

This board connects to other Windows 10 PCs without ANY troubles.

Any ideas what is going on?  Suggestions?

Thank you.

Phil



21
NXPTM M522XX, KINETIS and i.MX RT / Re: Change Baud Rate on Serial Port
« on: February 11, 2020, 05:15:43 PM »
Mark,

I should have known. Sorry.

Thank you for your quick reply.

Best regards,

Phil

22
NXPTM M522XX, KINETIS and i.MX RT / Change Baud Rate on Serial Port
« on: February 11, 2020, 01:22:21 AM »
Mark,

How do we change serial port settings on an open port?  I need to change the baud rate (and possibly other settings) on an open serial port.  I have used the serial port feature for years now. This is the first time I've needed to change a port setting in real time.

Thank you.

Phil

23
NXPTM M522XX, KINETIS and i.MX RT / Re: i.MX RT 1020 GPIO and Pin Multiplexing
« on: February 12, 2019, 08:59:43 PM »
Mark,

What is your plan regarding the i.MX series of application MCU's?  E.g. Are you planning to support these chips?  We are considering an i.MX8 for a project we are considering. We enjoy using uTasker and that would like to use uTasker, if the option exists.

Regards,

Phil

24
NXPTM M522XX, KINETIS and i.MX RT / Re: strtok
« on: February 06, 2019, 06:33:25 PM »
Thanks, Mark.

I would think that changing the "Target Processor" in the C Build settings would point to the correct standard libraries.

Regards,

Phil

25
NXPTM M522XX, KINETIS and i.MX RT / Re: strtok
« on: February 06, 2019, 12:17:50 AM »
Attached is the debug trail that shows the hard fault originated from the strtok string parse function.

26
NXPTM M522XX, KINETIS and i.MX RT / Re: strtok
« on: February 06, 2019, 12:12:14 AM »
Snipet of code in question:

void fnDoSwitch(unsigned char ucType, char *ptrInput)
{
   char *arg1;
   char buff[64];
   int i = -1;

   uStrcpy(buff,ptrInput);

   arg1 = strtok(buff, " \r");
...

27
NXPTM M522XX, KINETIS and i.MX RT / strtok
« on: February 06, 2019, 12:09:24 AM »
Mark,

Had something happen today that was rather strange.

I was reusing some code developed on a K64 and using this with a KL27. Interestingly, I ran into a bunch of problems related to the handling of strings. Simple things like defining an array of characters predefined to a 0 or using a strtok string function.  I know we had issues with strcpy and these types of functions but are these issues related?

Finest regards,

Phil

28
NXPTM M522XX, KINETIS and i.MX RT / Re: Timer Interrupt Overrun
« on: September 19, 2018, 12:04:47 AM »
That worked just fine.

Thank you once again, Mark.

Phil

29
NXPTM M522XX, KINETIS and i.MX RT / Timer Interrupt Overrun
« on: September 18, 2018, 11:27:09 PM »
Mark,

Here is a sample timer interrupt process that I am running:

   static TIMER_INTERRUPT_SETUP timer_setup = {0}; // interrupt configuration parameters

   timer_setup.int_type = TIMER_INTERRUPT;
   timer_setup.int_priority = PRIORITY_TIMERS;
   timer_setup.int_handler = IR_Receiver;
   timer_setup.timer_reference = 2; // timer channel 2
   timer_setup.timer_mode = (TIMER_PERIODIC | TIMER_US_VALUE); // single shot us timer
   timer_setup.timer_value = 281; // (562.5/2) // µs delay
//   timer_setup.timer_value = 1000;
   fnConfigureInterrupt((void *)&timer_setup); // enter interrupt and start timer

The function, IR_Receiver(), gets executed once every 281 us.  The problem is that it causes a hardware reset on my MK64 MCU.  If I change the timer_value to 1000 us, there is no lockup and the routine runs from beginning to end. It doesn't happen quick enough to get us the valid info we need but it works nonetheless.

I see examples of PIT timers and other timers with 100 us cycle times. I wouldn't think this would be a problem. But, my MCU resets.

Can you explain what is happening?

Regards,

Phil


30
NXPTM M522XX, KINETIS and i.MX RT / Re: Interrupt Control
« on: September 18, 2018, 07:53:41 PM »
Very interesting.

Thank you!

Phil

Pages: 1 [2] 3 4