Recent Posts

Pages: 1 ... 8 9 [10]
µTasker general / How to distribute my application as a uTasker Simulation?
« Last post by tdrobnak on September 14, 2021, 10:46:38 PM »
I would like to build my uTasker application as a distributable simulation on the PC.  I have done this, but the graphics for the Kinetis logo and the FRDM-KE15Z are missing when it is built using a setup project in Visual Studio 2017.  Does anyone know what I need to add to the VS setup project to add the missing graphics.  Also where are the missing items located in the uTasker directory?  I am sure there is a message on this forum that has this information on what is needed, but I cannot find it.  If you know where the message is, please send a link to it.

Thank you
µTasker general / Re: IAR EWARM v9 Support
« Last post by BrandonT on July 22, 2021, 01:25:13 PM »
I can confirm that IAR EWARM 9.10 does indeed work as expected.

I did, however, find that the IAR EWARM flashloader balked when attempting to flash my binary to the K60. I was able to determine that the flashloader was failing to handle the f_config section.

In order to allow the flashloader to write flash configuration, I had to modify the existing board file it used. I had to add the --enable_config_write parameter as indicated in the attached file: 
µTasker general / Re: IAR EWARM v9 Support
« Last post by mark on July 21, 2021, 02:37:19 PM »

I have been using 8.50.9.
From experience the exact version shouldn't make any noticeable difference - no code changes have been made for IAR since initial IAR 4 compatibility and the new IAR versions generally are due to changes in he IDE itself (editor, debugger) and the additional of more processor types that it supports.
In addition since the move form IAR4 to IAR5 (which lost compatibility with the IDE projects) subsequent generations have always been backward compatible.


µTasker general / IAR EWARM v9 Support
« Last post by BrandonT on July 21, 2021, 07:59:39 AM »
What is the latest version of IAR EWARM against which the pre-configured projects have been qualified? I am currently using IAR EWARM 9.10.
USB / Re: USB on Windows 10
« Last post by Phil on July 13, 2021, 11:52:49 PM »

Thank you. However, this did not resolve the problem.  I will come back to this later and step through the code and report.  It is also obvious that I need to update my copy of uTasker.

I will report back once I get my copy updated to the latest version of uTasker and I have walked through the code.

Best regards,

NXPTM M522XX, KINETIS and i.MX RT / Re: SD Card Format Speed
« Last post by AlexS 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 / Re: SD Card Format Speed
« Last post by mark on July 13, 2021, 07:13:20 PM »

That is a long time for the formatting to take - I expect maybe 30s or a minute if doing a quick format (which deletes the FAT but not all sectors - a full format (also wiping out old data in the sectors) will take a lot longer.

The mass storage task will be doing this by deleting a sector at a time and the sector writes (setting content to 0) will usually take about 4ms each. Then the task allows other tasks to run and continues with the next, repeating until finished.

What is the time gap between each iteration? Is there something running between each which slows the overall operation?

Ultimately the format time is the sum of the time to erase each sector in the FAT table (whereby there are 2 copies maintained and so the overall time is double) plus any other time added between iterations.



NXPTM M522XX, KINETIS and i.MX RT / SD Card Format Speed
« Last post by AlexS 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.

USB / Re: USB on Windows 10
« Last post by mark on July 13, 2021, 02:05:55 AM »
Hi Phil

Some time in June 2021 I had an experience with USB-MSD that would not operate well although the code is several years old and hadn't behaved like this before. With Windows 10 and possibly after a Windows update.

My feeling is that something has been sped up in the enumeration/initialisation and what I saw was that set-ups with data were sent while previous handshakes had no yet completely terminated (queued) and what would happen is that the receiver in the HW would lose synch with the data toggling and drop a reception frame believing its data toggle was incorrect. This causes the host to wait maybe 10..15s and then reset and re-enumerate where is would often then work.

To (hopefully) resolve this 'race-state' I added a modification to kinetis_USB_FS_OTG.h as follows:

    07.06.2021 Resynchronise data buffers when sending status stage to ensure no race state on subsequent SETUP reception+ DATA {14}

If you have access to this (it is in branch V2.0.0 of the GIT repository) you may find that it solves the issue - I haven't seen it since but haven't used USB device on the Kinetis a great deal since then.

This is the actual modification that you could build in otherwise, in fnProcessInput():

    switch (fnUSB_handle_frame(ucFrameType, (unsigned char *)ptUSB_BD_rx->ptrUSB_BD_Data, iEndpoint_ref, ptrUSB_HW)) { // generic handler routine
    case TERMINATE_ZERO_DATA:                                            // send zero data packet to complete status stage of control transfer
        if (iEndpoint_ref == 0) {                                        // {14} resynchronise data buffers when sending status stage
            if (&ptEndpointBD->usb_bd_rx_even == ptUSB_BD_rx) {
                ptEndpointBD->usb_bd_rx_even.ulUSB_BDControl |= (DATA_1);
                ptEndpointBD->usb_bd_rx_odd.ulUSB_BDControl &= ~DATA_1;
                ptEndpointBD->usb_bd_rx_odd.ulUSB_BDControl |= OWN;
            else {
                ptEndpointBD->usb_bd_rx_odd.ulUSB_BDControl |= (DATA_1);
                ptEndpointBD->usb_bd_rx_even.ulUSB_BDControl &= ~DATA_1;
                ptEndpointBD->usb_bd_rx_even.ulUSB_BDControl |= OWN;

        *ptrUSB_HW->ptr_ulUSB_BDControl = (OWN | ptrUSB_HW->ptrEndpoint->ulNextTxData0); // transmit a zero data packet on control endpoint
        _SIM_USB(0, USB_SIM_TX, iEndpoint_ref, ptrUSB_HW);
        ptrUSB_HW->ptrEndpoint->ulNextTxData0 ^= DATA_1;                 // toggle the data packet

It utilises the point when it is sending a zero frame status stage (just before the host will be allowed to send further sequences) to reset the rx toggle buffer to be sure that they are both ready to receive data 0 and data 1 tokens Previously there was a very small window where the data toggle may not have been correct in both and when the host very quickly sends a following setup and data to the two one may not be correct and thus the data dropped (since the HW thinks it is a repetition it ACKs it though, so the host thinks all is good but times out waiting for the actual response).



USB / Re: USB on Windows 10
« Last post by Phil on July 09, 2021, 01:42:00 AM »

Here is the USBPcap log from Wireshark, if this helps.


Pages: 1 ... 8 9 [10]