Recent Posts

Pages: 1 2 3 [4] 5 6 ... 10
31
NXPTM M522XX, KINETIS and i.MX RT / Re: un-enumerate USB Device loader?
« Last post by mark on March 08, 2024, 11:38:41 PM »
John

I think I have found a simple way to command disconnecting the USB device (and, if required, reconnecting it again.

USBHS0_USBCMD ^= USBHS_USBCMD_RS;

When USBHS_USBCMD_RS is set to 0 (stop mode) it removes its D+ pull-up and so is no longer detected by the host.
When it is set again it reconnects the D+ pull-up and goes to run mode again (and the host detects it and re-enumerates it).

I added this interface so that the registers don't need to be accessed directly (portable):

    fnConfigUSB(USB_DEVICE_REF, 0); // when the parameter is 0 it toggles the RUN mode in order to disconnect/reconnect

but it may not be the best method, so experimental at the moment.
You may be able to prove the suitability for your need by directly controlling it in the register.

Regards

Mark
32
NXPTM M522XX, KINETIS and i.MX RT / Re: un-enumerate USB Device loader?
« Last post by jackking on February 28, 2024, 08:10:29 PM »
Thanks, I will give that a shot.  I changed the loader to not automatically reset when the file is copied and verified via USB-MSD-DEVICE. 

I just want the USB to un-enumerate after the file copy so the drive disappears.  Then the user can either "try again" and reenumerate, or the update continues and then the user is prompted to reset (boot the application) when they choose.
33
NXPTM M522XX, KINETIS and i.MX RT / Re: un-enumerate USB Device loader?
« Last post by mark on February 28, 2024, 05:46:15 PM »
Hi

I understand that your serial loader is the device: After uploading a new file the loader will usually perform a SW reset in order to continue and this also causes the device to be disconnected.

As far as I can tell there is no de-installation method that disconnects a device itself but looking at the low level de-installation after a USB reset (in the HW USB interrupt _usb_hs_otg_isr_common()):

        if ((ulInterrupts & USBHS_USBINTR_URE) != 0) {                   // handle USB reset interrupt
            fnDeInitEndpoints(ptrHSUSB, Channel);                        // abort any active endpoints and free transfer buffers
            ptrHSUSB->EPCR0 = (USBHS_EPCR_RXE | USBHS_EPCR_RXR | USBHS_EPCR_TXE | USBHS_EPCR_TXR); // reset data toggle (synchronise) on endpoint 0
            ptrHSUSB->EPSETUPSR = ptrHSUSB->EPSETUPSR;                   // clear all setup token semaphores by reading the EPSETUSR register and writing the same value back
            ptrHSUSB->EPCOMPLETE = ptrHSUSB->EPCOMPLETE;                 // clear all the endpoint complete status bits by reading the EPCOMPLETE register and writing the same value back
#if defined _WINDOWS
            ptrHSUSB->EPSETUPSR = 0;
            ptrHSUSB->EPCOMPLETE = 0;
            ptrHSUSB->USBSTS = USBHS_USBSTS_PCI;                         // usually a port change interrupt follows a reset
#endif
            if ((ptrHSUSB->PORTSC1 & USBHS_PORTSC1_PR) == 0) {           // if we are too slow responding the port reset will have completed
                ptrHSUSB->USBCMD &= ~(USBHS_USBCMD_RS);                  // ensure not in run mode
                ptrHSUSB->USBCMD = USBHS_USBCMD_RST;                     // command a hardware reset
                fnUSBHS_init(((ptrHSUSB->PORTSC1 & USBHS_PORTSC1_PFSC) == 0), (QUEUE_LIMIT)Channel, ucHS_EndpointCount[Channel]); // re-initialise the controller
                ucUSBHS_state[Channel] = 0;
            }
            else {
                ucUSBHS_state[Channel] = USBHS_STATE_RESETTING;          // the ulpi is still detecting the reset state
            }
            ptrHSUSB->USBINTR &= ~(USBHS_USBINTR_SLE);                   // disable the suspend interrupt
            ptrHSUSB->PERIODICLISTBASE_DEVICEADDR = 0;                   // reset device address
            uDisable_Interrupt();                                        // ensure interrupts remain blocked when putting messages to queue
                fnUSB_handle_frame(USB_RESET_DETECTED, 0, 0, &hs_usb_hardware[Channel]); // generic handler routine
                hs_usb_hardware[Channel].ucUSBAddress = 0;               // reset the address to revert back to the default state
            uEnable_Interrupt();                                         // re-enable interrupts
        }

I suspect that it may be necessary to either provoke such a reset or else disable the USB (eg via  USB controller reset) and execute the same, or part of this.


Could you describe exactly the goal and also how it would best be tested?

Regards

Mark

34
µTasker general / Re: Method for Serial Loader to track application version?
« Last post by jackking on February 28, 2024, 05:37:37 PM »
Mark,

I have customized all loader methods (SD card, USB-MSD host and device and Serial) to store the incoming application into SDRAM first (since the part I am using does have a large SDRAM area).  Then I perform the update of Flash from the SDRAM data.  I can check the application version as part of this process, to perform a fast check before using a longer flash comparison and CRC calculation.  This would be compared to the existing application version in Flash.

I just didn't know if the "standard" uTasker application tools also had some way to add a version number when creating the application file, or whether I should handle this in my own way.

Thanks
JK
35
NXPTM M522XX, KINETIS and i.MX RT / Re: Serial Loader: Placing vars into SDRAM?
« Last post by mark on February 28, 2024, 05:32:50 PM »
Hi

Is the problem that the application is not running when the serial loader is build with the newer linker script?
I wouldn't expect the serial loader to change the behavior of the application since it doesn't configure any of the application's variables.

Regards

Mark
36
NXPTM M522XX, KINETIS and i.MX RT / Re: Serial Loader: Placing vars into SDRAM?
« Last post by mark on February 28, 2024, 05:30:44 PM »
Hi

I would expect the DCD to do the same as the SDRAM interface initialisation.
The DCD configuration is designed to be readable, eg.
                _DCD_WRITE_LONG_WORD(IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_00, GPIO_EMC_00_SEMC_DATA00),
                _DCD_WRITE_LONG_WORD(IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_01, GPIO_EMC_01_SEMC_DATA01),
                _DCD_WRITE_LONG_WORD(IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_02, GPIO_EMC_02_SEMC_DATA02),
                _DCD_WRITE_LONG_WORD(IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_03, GPIO_EMC_03_SEMC_DATA03),
                _DCD_WRITE_LONG_WORD(IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_04, GPIO_EMC_04_SEMC_DATA04),
                _DCD_WRITE_LONG_WORD(IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_05, GPIO_EMC_05_SEMC_DATA05),
                _DCD_WRITE_LONG_WORD(IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_06, GPIO_EMC_06_SEMC_DATA06),
                _DCD_WRITE_LONG_WORD(IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_07, GPIO_EMC_07_SEMC_DATA07),

so that it can also be compared with the code method, eg.
    _CONFIG_PERIPHERAL(GPIO_EMC_00, SEMC_DATA00, (IOMUXC_SW_PAD_CTL_PAD_HYS | IOMUXC_SW_PAD_CTL_PAD_PKE | IOMUXC_SW_PAD_CTL_PAD_SPEED_MAX | IOMUXC_SW_PAD_CTL_PAD_DSE_7 | IOMUXC_SW_PAD_CTL_PAD_SRE)); // select SEMC_DATA00 on GPIO4-00 - alt function 0 (direction input/output)
    _CONFIG_PERIPHERAL(GPIO_EMC_01, SEMC_DATA01, (IOMUXC_SW_PAD_CTL_PAD_HYS | IOMUXC_SW_PAD_CTL_PAD_PKE | IOMUXC_SW_PAD_CTL_PAD_SPEED_MAX | IOMUXC_SW_PAD_CTL_PAD_DSE_7 | IOMUXC_SW_PAD_CTL_PAD_SRE)); // select SEMC_DATA01 on GPIO4-01 - alt function 0 (direction input/output)
    _CONFIG_PERIPHERAL(GPIO_EMC_02, SEMC_DATA02, (IOMUXC_SW_PAD_CTL_PAD_HYS | IOMUXC_SW_PAD_CTL_PAD_PKE | IOMUXC_SW_PAD_CTL_PAD_SPEED_MAX | IOMUXC_SW_PAD_CTL_PAD_DSE_7 | IOMUXC_SW_PAD_CTL_PAD_SRE)); // select SEMC_DATA02 on GPIO4-02 - alt function 0 (direction input/output)
    _CONFIG_PERIPHERAL(GPIO_EMC_03, SEMC_DATA03, (IOMUXC_SW_PAD_CTL_PAD_HYS | IOMUXC_SW_PAD_CTL_PAD_PKE | IOMUXC_SW_PAD_CTL_PAD_SPEED_MAX | IOMUXC_SW_PAD_CTL_PAD_DSE_7 | IOMUXC_SW_PAD_CTL_PAD_SRE)); // select SEMC_DATA03 on GPIO4-03 - alt function 0 (direction input/output)
    _CONFIG_PERIPHERAL(GPIO_EMC_04, SEMC_DATA04, (IOMUXC_SW_PAD_CTL_PAD_HYS | IOMUXC_SW_PAD_CTL_PAD_PKE | IOMUXC_SW_PAD_CTL_PAD_SPEED_MAX | IOMUXC_SW_PAD_CTL_PAD_DSE_7 | IOMUXC_SW_PAD_CTL_PAD_SRE)); // select SEMC_DATA04 on GPIO4-04 - alt function 0 (direction input/output)
    _CONFIG_PERIPHERAL(GPIO_EMC_05, SEMC_DATA05, (IOMUXC_SW_PAD_CTL_PAD_HYS | IOMUXC_SW_PAD_CTL_PAD_PKE | IOMUXC_SW_PAD_CTL_PAD_SPEED_MAX | IOMUXC_SW_PAD_CTL_PAD_DSE_7 | IOMUXC_SW_PAD_CTL_PAD_SRE)); // select SEMC_DATA05 on GPIO4-05 - alt function 0 (direction input/output)
    _CONFIG_PERIPHERAL(GPIO_EMC_06, SEMC_DATA06, (IOMUXC_SW_PAD_CTL_PAD_HYS | IOMUXC_SW_PAD_CTL_PAD_PKE | IOMUXC_SW_PAD_CTL_PAD_SPEED_MAX | IOMUXC_SW_PAD_CTL_PAD_DSE_7 | IOMUXC_SW_PAD_CTL_PAD_SRE)); // select SEMC_DATA06 on GPIO4-06 - alt function 0 (direction input/output)
    _CONFIG_PERIPHERAL(GPIO_EMC_07, SEMC_DATA07, (IOMUXC_SW_PAD_CTL_PAD_HYS | IOMUXC_SW_PAD_CTL_PAD_PKE | IOMUXC_SW_PAD_CTL_PAD_SPEED_MAX | IOMUXC_SW_PAD_CTL_PAD_DSE_7 | IOMUXC_SW_PAD_CTL_PAD_SRE)); // select SEMC_DATA07 on GPIO4-07 - alt function 0 (direction input/output)

remembering that it is the primary loader (uTaskerBoot) that supplies the DCD.

Regards

Mark
37
µTasker general / Re: Method for Serial Loader to track application version?
« Last post by mark on February 28, 2024, 05:08:57 PM »
Hi

How is the incoming data being received?

When running the (stand-alone) boot loader, the original application is first deleted before receiving and so differences can't be checked - the exception is when loading form SD card or memory stick where the new code is first compared with the original.

If you have a application header I assume you are using an XiP image, where it would be a good idea to put an application version at a defined location in this. Otherwise, the header (with project number, application length and CRC) could also be used since changes to the application would (normally) be recognised by a change in its size and/or CRC).

Regards

Mark
38
µTasker general / Method for Serial Loader to track application version?
« Last post by jackking on February 27, 2024, 11:58:22 PM »
I am looking at using a version number on my application to see if the Serial Loader should perform an update, instead of doing a byte for byte check of flash to compare the current application with the incoming file to see if they are the same.

Is there already this concept built into the Serial Loader?   

Otherwise, I will look at modifying the application header to include a version in the update file and check this against the application in flash with a modified Serial Loader.

thanks
JK
39
NXPTM M522XX, KINETIS and i.MX RT / Re: Serial Loader: Placing vars into SDRAM?
« Last post by jackking on February 27, 2024, 04:52:51 PM »
I did a little more investigating on this, and it seems there are still some problems with the modified linker files in later MCUXpresso versions. 

My uploaded application could not run after booting from the Serial Loader. 

Moving the same application over to MCUXpresso 11.4 and using the old linker scripts, the same application would run.

40
NXPTM M522XX, KINETIS and i.MX RT / un-enumerate USB Device loader?
« Last post by jackking on February 27, 2024, 04:49:01 PM »
I would like to un-enumerate (disconnect) the uTasker USB device after a successful upload of a firmware file.  Is there a way to create a function opposite of the
Code: [Select]
fnConfigureUSB(void) function to call before suspending the task?

thanks
JK
Pages: 1 2 3 [4] 5 6 ... 10