Messages

16

NXP^TM M522XX, KINETIS and i.MX RT / Re: un-enumerate USB Device loader?

« 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

17

NXP^TM M522XX, KINETIS and i.MX RT / Re: Serial Loader: Placing vars into SDRAM?

« 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

18

NXP^TM M522XX, KINETIS and i.MX RT / Re: Serial Loader: Placing vars into SDRAM?

« 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

19

µTasker general / Re: Method for Serial Loader to track application version?

« 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

20

NXP^TM M522XX, KINETIS and i.MX RT / Re: Serial Loader: Placing vars into SDRAM?

« on: February 05, 2024, 11:09:40 PM »

Hi

If you enable
#define BOOT_LOADER_SUPPORTS_SDRAM                   // enable when the boot loader is to configure SDRAM for subsequent application use (or when application runs in SDRAM)
when building the primary loader the SDRAM can be used by the serial loader or the application without needing to configure there.

The SDRAM is located at 0x80000000 [SDRAM_ADDR] and so the easiest way to store data to is to use a pointer as follows:

Code: [Select]

unsigned char *ptrSDRAM = (unsigned char *)SDRAM_ADDR;
unsigned char ucByte = 0;
unsigned long ulTestCnt = (4 * 1024 * 1024);
while (ulTestCnt--  != 0) {
    *ptrSDRAM++ = ucByte++;
}which should, as example,  leave a 0x00, 0x01, 0x02... pattern throughout 4Meg of the SDRAM.

Regards

Mark

21

NXP^TM M522XX, KINETIS and i.MX RT / i.MX RT Guide to Setting Peripheral Functions

« on: January 24, 2024, 08:26:01 PM »

Hi All

This example shows how to configure a peripheral pin with help if the _CONFIG_PERIPHERAL() or _CONFIG_PERIPHERAL_LOOPBACK() macros.

As an example I will configure LPSPI3_SCK function on the pin referenced as GPIO_AD_B1_15 (assuming an i.MX RT 106x)


This is the code:

IOMUXC_LPSPI3_SCK_SELECT_INPUT = IOMUXC_LPSPI3_SCK_SELECT_INPUT_GPIO_AD_B1_15_ALT2;
_CONFIG_PERIPHERAL_LOOPBACK(GPIO_AD_B1_15, LPSPI3_SCK, (IOMUXC_SW_PAD_CTL_PAD_PKE | IOMUXC_SW_PAD_CTL_PAD_SPEED_MEDIUM | IOMUXC_SW_PAD_CTL_PAD_DSE_6));

and this is how one arrives at it:

1. One needs to know which GPIO reference (PAD) it is on -> GPIO_AD_B1_15 in this case

2. One searches for this in iMX.h until one finds the list of mux options belonging to it

    #define GPIO_AD_B1_15_FLEXSPIA_SS0_B           (IOMUXC_SW_MUX_CTL_PAD_MUX_MODE_ALT0)
    #define GPIO_AD_B1_15_ACMP_OUT03               (IOMUXC_SW_MUX_CTL_PAD_MUX_MODE_ALT1)
    #define GPIO_AD_B1_15_LPSPI3_SCK               (IOMUXC_SW_MUX_CTL_PAD_MUX_MODE_ALT2)
    #define GPIO_AD_B1_15_SAI1_TX_SYNC             (IOMUXC_SW_MUX_CTL_PAD_MUX_MODE_ALT3)
    #define GPIO_AD_B1_15_CSI_DATA02               (IOMUXC_SW_MUX_CTL_PAD_MUX_MODE_ALT4)
    #define GPIO_AD_B1_15_GPIO1_IO31               (IOMUXC_SW_MUX_CTL_PAD_MUX_MODE_ALT5)
    #define GPIO_AD_B1_15_USDHC2_DATA7             (IOMUXC_SW_MUX_CTL_PAD_MUX_MODE_ALT6)
    #define GPIO_AD_B1_15_KPP_COL00                (IOMUXC_SW_MUX_CTL_PAD_MUX_MODE_ALT7)
    #if defined iMX_RT106X
        #define GPIO_AD_B1_15_ENET2_1588_EVENT3_IN (IOMUXC_SW_MUX_CTL_PAD_MUX_MODE_ALT8)
        #define GPIO_AD_B1_15_FLEXIO3_FLEXIO15     (IOMUXC_SW_MUX_CTL_PAD_MUX_MODE_ALT9)
    #endif


3. One take the full mux name (GPIO_AD_B1_15_LPSPI3_SCK) and insert it into the macro, with a comma separating the GPIO reference and the peripheral mux reference belonging to that GPIO:

 _CONFIG_PERIPHERAL_LOOPBACK(GPIO_AD_B1_15, LPSPI3_SCK, (IOMUXC_SW_PAD_CTL_PAD_PKE | IOMUXC_SW_PAD_CTL_PAD_SPEED_MEDIUM | IOMUXC_SW_PAD_CTL_PAD_DSE_6));

This can't be done wrong since it will not compile if incorrect GPIOs aad peripherals are attempted.
The characteristics (last parameter) can be modified to control drive strength and slew rate, etc.

4. Note that either _CONFIG_PERIPHERAL() or _CONFIG_PERIPHERAL_LOOPBACK() is used.
The first is used in most cases but the _CONFIG_PERIPHERAL_LOOPBACK() one is needed for some signals that are generated to be driven onto the pin and also need to be looped back internally to be driven to the peripheral itself. In the case of the LPSPI master operation this MUST be used for the CLK otherwise the clock will be generated but not be connected internally, meaning it won't work completely.

5. Some peripheral pins need an additional sub-muxing setting since they can be located on multiple pins.

IOMUXC_LPSPI3_SCK_SELECT_INPUT = IOMUXC_LPSPI3_SCK_SELECT_INPUT_GPIO_AD_B1_15_ALT2;

To see whether it is necessary it is easiest to search iMX.h for IOMUXC_x (where x is the name of the peripheral signal) -> IOMUXC_LPSPI3_SCK
If it shows up as a IOMUX_xxxx_SELECT_INPUT register, like:

    #define IOMUXC_LPSPI3_SCK_SELECT_INPUT             *(unsigned long *)(IOMUXC_SW_BLOCK + 0x0510) // LPSPI3_SCK_SELECT_INPUT DAISY register
        #define IOMUXC_LPSPI3_SCK_SELECT_INPUT_GPIO_AD_B0_00_ALT7 0x00000000 // select GPIO_AD_B0_00 for mode: ALT7
        #define IOMUXC_LPSPI3_SCK_SELECT_INPUT_GPIO_AD_B1_15_ALT2 0x00000001 // select GPIO_AD_B1_15 for mode: ALT2

it should be set.

IOMUXC_LPSPI3_SCK_SELECT_INPUT = IOMUXC_LPSPI3_SCK_SELECT_INPUT_GPIO_AD_B1_15_ALT2;


One can get away without setting it in case the 0x00000000 is true since it defaults to that, but as good practice it is best to always set the value. It also means that when modifying such configurations one doesn't forget to check and set the value accordingly.

If there is no corresponding IOMUXC_xxxxx_SELECT_INPUT register there is no sub-mux setting to be made.


6. After making such changes one can run the simulator and hover the mouse over the pins one wants to check and it will show the present GPIO/peripheral function so one can easily verify that it is correct before testing on HW.



Regards

Mark

22

NXP^TM M522XX, KINETIS and i.MX RT / Re: Compiler Issue

« on: January 24, 2024, 08:13:58 PM »

Hi Neil

I have attached the missing folder as zip file.

Regards

Mark

23

NXP^TM M522XX, KINETIS and i.MX RT / Re: Compiler Issue

« on: January 19, 2024, 09:42:03 PM »

Hi Neil

It is a number of years since I last worked with Coldifre and with the CW IDEs, therefore I haven't had any practice for a very long time.
However there is a CW10 project in
\Applications\uTaskerV1.4\CodeWarrior_M522XX_CW10
and the IDE's project settings are in \Applications\uTaskerV1.4\CodeWarrior_M522XX_CW10\ProjectSettings - the content of that folder needs to be copied to the root of the project (above \Applications) and that should allow your to test that the CW 10 or 11 version can build the reference project [I haven't tested this for a very long time so can't guarantee there is not an incompatibility somewhere in the later versions but any issues will be due to prototype changes or new defines needing to be set somewhere, thus easily fixable].

Good luck

Regards

Mark

24

NXP^TM M522XX, KINETIS and i.MX RT / Re: Using different pins for SD VSELECT, PWREN and CARD DETECT?

« on: December 28, 2023, 12:37:46 AM »

Hi

The selections are in the file app_hw_xxxx.h since it is specific to the HW.
Assuming you are working with an i.MX RT the default tends to be

            #define SDCARD_DETECT_INPUT_INTERRUPT                        // use card detect interrupt rather than polling the card
            #define SDCARD_DETECTION()      ((SDHC_PRSSTAT & SDHC_PRSSTAT_CINST) != 0) // card detection input

and if SDHC_DETECT_INTERRUPT_GPIO is enabled a GPIO can be used instead.

but it can be polled (via GPIO) with

#define SDCARD_DETECT_INPUT_POLL                                 // use card detect switch for detection polling (use together with T_CHECK_CARD_REMOVAL)

or polled by reading an SD card register if neither is enabled.

There is no specific VSEL control for the i.MX RT but if needed it can be added to the POWER_TO_SD_CARD() macro via a GPIO.

Regards

Mark


P.S: Note that the i.MX RT project has only used the SDHC's dedicated card detection line and so I found that I needed to adjust some conditional defines in the mass storage code so that the GPIO interrupt initialisation was included (for example). I have checked these changes in but not tested on HW (only in simulator). I used this on an RT 1020:

            #define SDCARD_DETECT_INPUT_INTERRUPT                        // use card detect interrupt rather than polling the card
            #define SDHC_DETECT_INTERRUPT_GPIO                           // use general GPIO rather than the SDHC's detect input
            #if defined SDHC_DETECT_INTERRUPT_GPIO
                #define SDCARD_DETECT_PORT     PORT2
                #define SDCARD_DETECT_PIN      PIN_GPIO_EMC_00_GPIO2_IO00
                #define PRIORITY_SDCARD_DETECT_PORT_INT     PRIORITY_PORT_2_LOW
                #define SDCARD_DETECTION()      (_READ_PORT_MASK(2, SDCARD_DETECT_PIN) == 0) // card detection input

25

NXP^TM M522XX, KINETIS and i.MX RT / Re: UDP socket buffer size

« on: November 10, 2023, 11:19:52 PM »

Hi Neil

As long as the Ethernet Rx buffer can hold the UDP reception it will be adequate - your receive the UDP packet directly in that buffer:

#define LAN_BUFFER_SIZE        1518

is adequate for the largest Ethernet frame (excluding jumbo frames) and so UDP payload (over IPv4) is limited to 1492 bytes (I believe) - this assumes no fragmentation, which will be the case in modern local networks.

Regards

Mark

26

µTasker general / Re: FRDM-K64F FTP

« on: October 25, 2023, 09:09:10 PM »

Hi

The bat file that does this just needs to be double clicked and therefore it is not possible to do anything wrong with the action itself.

However you may have a firewall issue that is allowing the FTP command connection to be established but not the FTP data connection.
Try recording the Ethernet activity with wireshark to see what actually happens and also try temporarily disabling and firewall that you have.

Regards

Mark

27

µTasker general / Re: HTML parameters update, however browser controls don't indicate

« on: October 03, 2023, 11:43:12 PM »

Hi Ray

Check the user function:

static unsigned char fnIsSelected(unsigned char *ptrBuffer)

This should handle the decision as to whether the particular entry is selected or not but I don't think it is handling the 'C' case.

Try adding something like

case 'C':
if (*ptrBuffer == 'S') { // daylight saving case
    if (the box should be checked) {
        return IS_CHECKED;
    }
}
else if (*ptrBuffer matches the one that is presently selected) { // time zone case assumed
        return IS_SELECTED;                                              // select the entry
}
break;

Regards

Mark

28

µTasker general / Re: How to configure SPI_FILE_SYSTEM to work with serial loader

« on: September 18, 2023, 12:33:51 PM »

Hi Ray

>> #define ACTIVE_FILE_SYSTEM

This is used to enable the uFileSystem which tends to be used with the FTP/HTTP interfaces. However when no Ethernet is enable in the serial loader

#define _NO_FILE_INTERFACE                                           // code size optimisation

is set, which disables some of the support so that the size is optimised.



>> change line 217  from 64 to 476  #define UTASKER_APP_END   (unsigned char *)(UTASKER_APP_START + (476 * 1024)) // use entire chip

You may need to reduce the size by the application's parameter system size so that the parameters are not deleted when loading new code.

Otherwise I haven't been able to reproduce the project so it would be simpler if you send me your config.h and app_hw_kinetis.h files.

If I have understood correctly you are using USE_USB_MSD in the application (a USB-MSD device to SD card / SPI Flash), with the following configuration note:
            #define USE_USB_MSD                                          // needs SD card to compile (or alternatives FLASH_FAT / SPI_FLASH_FAT / FAT_EMULATION)

In the serial loader the same can be set but it looks to be dedicated to the SD card:
#define USE_USB_MSD                                              // full USB-MSD to SD card interface on USB (no emulated loader function) - requires SDCARD_SUPPORT (USB_MSD_DEVICE_LOADER can be disabled)

My initial feeling is that some addition code configuration may be required to allow the same operation.

If you send me the two header files it would be easier for me to check.

Regards

Mark

29

µTasker general / Re: How to configure SPI_FILE_SYSTEM to work with serial loader

« on: September 11, 2023, 11:21:20 PM »

Hi Ray

fnWriteParallelFlash() is only available in the Coldfire project so EXT_FLASH_FILE_SYSTEM should not be defined in the Kinetis project.

Regards

Mark

30

µTasker general / Re: How to configure SPI_FILE_SYSTEM to work with serial loader

« on: September 05, 2023, 02:56:08 AM »

Hi Ray

I don't see the problem by just looking at the configuration.

If I understand correctly you have an application that uses an external SPI memory as FAT media and a host works with it via USB (USB-MSD). Can your application also access the FAT and can it format it? If it can you can use the W25QXXX.ini from the simulation of the application for the serial loader simulation (by copying it to the serial loader's simulation folder). This may help debug the serial loader (when it has a known formatted FAT in the SPI Flash) to see why this is maybe not recognised as the application does. You could check that both application and serial loader are accessing the content at the same address (for example) when both mount the FAT.

Regards

Mark