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

Pages: [1] 2 3 ... 217
1
The ADC interface 'attempts' to be compatible across processors and ADC types so some of the values will not do anything but can be left so that the interface remains operational with those that need them, or react to them.

The calibration flag should only be set once, the first time the interface is called (for each ADC).

The easiest way to learn the interface is to run the main application in Visual Studio and step through the code so that the effect of flags can be seen. The idea is to start with a basic interface that has a certain amount of features, and basic compatibility although the internal workings may not be highly efficient due to this. One can see which paths are used (and needed) and take these into a custom function if speed is important.

Regards

Mark

2
Hi

The ADC pins are found here: https://www.utasker.com/iMX/iMXRT1060/iMX_RT_1060.xls

To select ADC1_IN9 use
adc_setup.int_adc_controller = iMX_ADC_1;                            // first i.MX RT ADC
adc_setup.int_adc_bit = ADC_SE9_SINGLE;

Optionally pullup/down can also be defined using ADC_INPUT_PULL_DOWN, ADC_INPUT_PULL_UP or ADC_INPUT_PULL_UP_WEAK to the adc_setup.int_adc_mode details.

which causes the configuration (in the ADC driver) with

_CONFIG_PORT_INPUT(1, ADC1_IN9_GPIO_AD_B1_04_GPIO1_IO20, ulPinCharacteristic);


For ADC1_IN10 change adc_setup.int_adc_bit to ADC_SE10_SINGLE.


Presently your code is configuring but not converting (default is to use a conversion interrupt, which you have disabled).
Add ADC_GET_RESULT so that it will do a blocking conversion and return the value.
Note that samples.ucADC_status will then contain ADC_RESULT_VALID, indicating that the result is valid (presently you will find that it is not the case).

Note that I haven't a great many features in the present ADC driver version for the i.MX RT and so HW trigger modes and chaining are not integrated. If you tell me which STK reference contains the method that you would like to use I can add that to the interface.
The HW triggering levels do work well since I have used these successfully in some products.

Regards

Mark





3
NXPTM M522XX, KINETIS and i.MX RT / Re: Caching of (XiP) Flash?
« on: March 14, 2024, 12:03:47 AM »
Note also that using the fnGetParsFile() method to read to a buffer also bypasses any caching. Only the XiP (memory mapped) accesses can be cached.

4
NXPTM M522XX, KINETIS and i.MX RT / Re: Caching of (XiP) Flash?
« on: March 13, 2024, 02:12:07 AM »
The FlexSpi has a cache.

Try
        FLEX_SPI_AHBCR = FLEX_SPI_AHBCR_READADDROPT;                     // disable FlexSPI caching

since that worked for me when I had a similar issue.
It completely disables it but, seeing as the serial loader is running in RAM, there will be no performance disadvantage just turning it off.

Regards

Mark

5
 :)

6
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

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


8
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

9
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

10
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

11
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

12
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

13
NXPTM 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

14
NXPTM 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


15
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





Pages: [1] 2 3 ... 217