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] 4 5 ... 218
31
Hi Ray

In fnHandleARP_response()

you could try removing the registration of received ARP requests that were not destined to your IP address as follows, which may help reduce the ARP entries that you are not interested in.

    else {                                                               // it was not an ARP to our IP address but we can still add it to our table or refresh the entry
    #if !defined ARP_IGNORE_FOREIGN_ENTRIES
        if (uMemcmp(ucRequestingIP, cucBroadcast, IPV4_LENGTH) != 0) {   // ignore broadcasts
            fnAddARP(ucRequestingIP, ucRequestingMAC, &arp_details);     // {14}
        }
    #endif
    #if defined USE_IP_STATS
        fnIncrementEthernetStats(SEEN_FOREIGN_ARP_FRAMES, _NETWORK_ID);  // update statistics for foreign addresses
    #endif
    }


ARP entries will probably not be an issue though.


Looking at the wireshark recording I see that the traps are initially sent to 172.22.1.94

15mins later I see that there are ARPs being sent out to resolve the address 172.22.0.1, which are not answered. These maybe due to the traps that you are trying to send but may be due to other causes.

In any case you need to find out why the ARP (assuming associated with the trap after a certain time) is presumably being sent to a different address, potentially on a different sub-net, since this is possibly the issue.
Since you are working with the simulator this should be quite easy to do:
- set a break point in the ARP transmission when it starts to see how the destination address is being defined.
- let it run until the problem starts
- enable the break point again to see what is causing the ARP to be sent (possibly the trap want to send data) and compare how the destination address is being defined. I expect you'll find a difference that will explain why it stops working after a certain time.
- Traps can be sent form anywhere and don't need to be called in the SNMP task.

Regards

Mark

32
NXPTM M522XX, KINETIS and i.MX RT / i.MX RT TEMPMON
« on: July 11, 2023, 09:30:29 PM »
The i.MX RT 10xx includes a temperature monitor module (TEMPMON) that allows interrupts to be generated if the core temperature exceeds two programmable high temperature levels or falls below a low programmable lower limit level.

Software can also read the present die temperature at any time.

In order for it to work correctly it needs the bandgap reference to be enabled, plus the 480MHz PLL and the 32kHz RTC modules to be operating.

The temperature monitor is factory calibrated and the calibration values can be read from the HW_OCOTP_ANA1 registers. These are used by software to extrapolate the temperature and also to correctly set temperature limits.

The support in the µTasker project is enabled with the define SUPPORT_TEMPMON which adds an interface to read the core temperature via the ADC API in a compatible manner for projects that also run on processors that use ADC based temperature reading.

An example of reading the temperature periodically can be activated in ADC_Timers.h by activating the define ADC_INTERNAL_TEMPERATURE when using the ADC reference. For compatibility the ADC API is used with the input set to

adc_setup.int_adc_bit = ADC_TEMP_SENSOR; // ADC internal temperature

which is how ADC based temperature reading is performed.

Although there is no interrupt generated when the measurement has completed such an interrupt is emulated so that applications remain compatible. The only difference is that the result returned when collecting the value is in °C x 100 (allowing hundredth of degree resolution) and not the raw ADC value itself. Therefore the only modification at the application level is to remove any HW specific conversion that may originally have been performed and use the result directly (or after modification to the desired form). The following shows retrieving and rounding to 1°C resolution:

Code: [Select]
ADC_SETUP adc_setup; // interrupt configuration parameters
ADC_RESULTS results;
adc_setup.int_type = ADC_INTERRUPT; // identifier
adc_setup.int_adc_mode = (ADC_READ_ONLY | ADC_GET_RESULT);
adc_setup.int_adc_controller = 0;
adc_setup.int_adc_result = &results;
fnConfigureInterrupt((void *)&adc_setup);
results.sADC_value[0] += 50;
results.sADC_value[0] /= 100; // the approximate temperature
rounded up/down to 1°C
fnDebugDec(results.sADC_value[0], DISPLAY_NEGATIVE);
fnDebugMsg(" degC\r\n");

In this particular case the conversion was started previously and it shows just the subsequent retrieval. The conversion was started using the standard API for the ADC with the ADC_TEMP_SENSOR defined as input. When multiple ADC controllers are implemented in the i.MX RT the same one should be referenced for the conversion and retrieval, although there is only one TEMPMON module shared by both and the ADC controller is not actually used.

33
NXPTM M522XX, KINETIS and i.MX RT / Re: Closing and reopening handles
« on: June 21, 2023, 03:24:47 PM »
Hi Neil

You can call with the ucDriverMode set to MODIFY_CONFIG is you want to change the UART settings (such as the baud rate).

The UART doesn't support close and re-open since this is something that is never (up to now) needed in an embedded system. It would be possible since the driver handles a close but it would require the UART's memory management to be changed to use dynamic heap (such as when the buffer sizes need to change) rather than uMalloc() as it presently uses.

If you want to stop the UART for some time you can also do

fnDriver( GSMPortID, ( TX_OFF | RX_OFF ), 0 );

and then later re-enable it with

fnDriver( GSMPortID, ( TX_ON | RX_ON ), 0 );

Regards

Mark


34
Hi Alex

If you look in app_hw_stm32.h there are some setups for SDHC and SPI interfaces.

For example:

Code: [Select]
                // Configure to suit SD card SPI mode at between 100k and 400k
                //
                #define SDCARD_CS                  PORTC_BIT11
                #define SDCARD_MISO                PORTB_BIT4
                #define SDCARD_MOSI                PORTB_BIT5
                #define SDCARD_CLK                 PORTB_BIT3
                #define INITIALISE_SPI_SD_INTERFACE() _CONFIG_PORT_OUTPUT(C, SDCARD_CS, (OUTPUT_FAST | OUTPUT_PUSH_PULL)); _SETBITS(C, SDCARD_CS); \
                        POWER_UP(APB1, RCC_APB1ENR_SPI3EN); \
                        _CONFIG_PERIPHERAL_INPUT(B, (PERIPHERAL_SPI3_I2S3ext), (SDCARD_MISO), (INPUT_PULL_UP)); \
                        _CONFIG_PERIPHERAL_OUTPUT(B, (PERIPHERAL_SPI3_I2S3ext), (SDCARD_CLK | SDCARD_MOSI), (OUTPUT_PUSH_PULL | OUTPUT_MEDIUM)); \
                        RCC_APB1RSTR |= RCC_APB1RSTR_SPI3RST; RCC_APB1RSTR &= ~RCC_APB1RSTR_SPI3RST; \
                        SPI3_CR1 = (SPICR1_BR_PCLK2_DIV128 | SPICR1_MSTR | SPICR1_SSI | SPICR1_CPOL | SPICR1_CPHA | SPICR1_SSM); \
                        SPI3_I2SCFGR = 0; \
                        SPI3_CR1 = (SPICR1_SPE | SPICR1_BR_PCLK2_DIV128 | SPICR1_MSTR | SPICR1_SSI | SPICR1_CPOL | SPICR1_CPHA | SPICR1_SSM);

                #define SHARE_SPI                                        // ensure that LCD operations are terminated to avoid conflicts
                #define POWER_UP_SD_CARD()                               // apply power to the SD card if appropriate
                #define ENABLE_SPI_SD_OPERATION()
                // Set maximum speed
                //
                #define SET_SPI_SD_INTERFACE_FULL_SPEED() SPI3_CR1 = (SPICR1_SPE | SPICR1_BR_PCLK2_DIV2 | SPICR1_MSTR | SPICR1_SSI | SPICR1_CPOL | SPICR1_CPHA | SPICR1_SSM)
                #if defined _WINDOWS
                    #define WRITE_SPI_CMD(byte)      SPI3_DR = (unsigned short)byte; SPI3_DR = _fnSimSD_write((unsigned char)byte)
                    #define WAIT_TRANSMISSON_END()   while ((SPI3_SR & SPISR_TXE) == 0) { SPI3_SR |= SPISR_TXE;} \
                                                     while (SPI3_SR & SPISR_BSY) {SPI3_SR &= ~SPISR_BSY;}
                #else
                    #define WRITE_SPI_CMD(byte)      SPI3_DR = (unsigned short)byte
                    #define WAIT_TRANSMISSON_END()   while ((SPI3_SR & SPISR_TXE) == 0) {} \
                                                     while (SPI3_SR & SPISR_BSY)
                #endif
                #define READ_SPI_DATA()              (unsigned char)SPI3_DR

                #define SET_SD_DI_CS_HIGH()           _CONFIG_PORT_OUTPUT(C, SDCARD_MISO, (OUTPUT_FAST | OUTPUT_PUSH_PULL)); _SETBITS(C, SDCARD_MISO); _SETBITS(C, SDCARD_CS) // force DI and CS lines high ready for the initialisation sequence
                #define SET_SD_CARD_MODE()            _CONFIG_PORT_INPUT(C, (SDCARD_MISO), (INPUT_PULL_UP | PULLUP_BIT11));
                #define SET_SD_CS_LOW()               _CLEARBITS(C, SDCARD_CS) // assert the CS line of the SD card to be read
                #define SET_SD_CS_HIGH()              _SETBITS(C, SDCARD_CS) // negate the CS line of the SD card to be read

Using this as reference you can adapt the SPI instance and pins to match your HW.

Regards

Mark


35
Hi Ray

I am please that you managed to catch the issue.

Regards

Mark

36
Hi Ray

don't forget that the PHY has an address that is set via straps. Make sure that its address matches PHY_ADDRESS.
Or you can try SCAN_PHY_ADD which will scan all possible addresses to see whether the ID can be read on one of them.

Good luck

Regards

Mark


37
Hi Ray

In kinetis.c

#if (defined ETH_INTERFACE && defined ETHERNET_AVAILABLE && !defined NO_INTERNAL_ETHERNET)
/* =================================================================== */
/*                          Ethernet Controller                        */
/* =================================================================== */
    #include "kinetis_ENET.h"                                            // include Ethernet controller hardware driver code
#endif


It is not possible to include it from a header file since it contains code and then the code would be included in multiple locations.

VS normally handles highlighting well. Try a clean/rebuild which may sort it out.

Regards

Mark

38
Hi

If you have code that may take a long time and causes a SW WDOG timeout (but not due to an error, as such) you can increase the watchdog value in (for example the i.MX RT project)

#define ACTIVATE_WATCHDOG()     UNLOCK_WDOG3(); WDOG3_TOVAL = (2 * 32000); WDOG3_WIN = 0; WDOG3_CS = (WDOG_CS_CLK_LPO | WDOG_CS_FLG | WDOG_CS_CMD32EN | WDOG_CS_EN); // enable watchdog with 2s timeout (32kHz reference)

or add re-triggers in the code [fnRetriggerWatchdog()].

To identify the location you can add a HW timer (single-shot that can be re-triggered) configured to a slightly lower timeout than the watchdog timeout.
Add a re-trigger of it to the macro
Code: [Select]
TOGGLE_WATCHDOG_LED()
and set a break point in its interrupt handler.

If this interrupt fires you can look to see which code is executing (step out of the interrupt or look at the call stack).

Regards

Mark

39
Hi Ray

I don't think there is anything in the newer GCC versions that are greatly beneficial and older ones work fine:
Maybe there are some better warning messages in newer ones (pointing out potential code issues) but these are not critical.

Regards

Mark

40
Hi All

With the release of NXP's MCUXpresso V11.5, which is supplied with a newer version of the GCC tool chain, i.MX RT projects could no longer be build due to an incompatibility in the linker scripts.
Interestingly this however didn't affect Kinetis projects, where the same incompatibility was not experienced.

Originally attempts were made to identify what had changed and work around it but this proved to be a dead-end and so finally a new linker script was generated using the NXP SDK and then adapted to suit the uTasker code (such as inserting the same variable section references so that the initialisation code didn't need to be modified).

The result is that by swapping out original linker scripts against newer ones projects can be built with MCUXpresso versions pre-V11.5 and post.

At this time there are still some linker scripts to be adapted and tested but for the main usage I have attached the ones that can already be used (later they will be checked into the repository for general use)

- iMX_RT_10XX_FlexSPI_NOR.ld   This can be saved to \Applications\uTaskerBoot\GNU_iMX (overwriting the original) and allows the primary loader to be built for i.MX RT 10xx parts (excluding the i.MX RT 1064)

- iMX_RT_1064_FlexSPI_NOR.ld. This can be saved to \Applications\uTaskerBoot\GNU_iMX (overwriting the original) and allows the primary loader to be built for  the i.MX RT 1064

- iMX_RT_10XX_FlexSPI_NOR_BOOT.ld. This can be saved to \Applications\uTaskerSerialBoot\GNU_iMX (overwriting the original) and also to \Applications\uTaskerV1.4\GNU_iMX and allows the secondary loaders and application to be built for i.MX RT 10xx parts operating in RAM (the main operation configuration and always used by the serial loaders).

- iMX_RT_10XX_SDP_Boot.ld. This can be saved to \Applications\uTaskerSerialBoot\GNU_iMX (overwriting the original) and allows serial download protocol images for i.MX RT 10xx parts. This tends to be built in parallel with the serial loader and so, even if the SDP outputs are never used, it will stop the build failing.

Regards

Mark

41
Hi

The 0.65mm pitch part is designed/intended for 4 layer boards and the NXP EVKs are 4-layer designs allowing all pins to be used and also (according to them) passes FCC tests.

The only drawback is that some room around the device is needed for fan-out of the signal lines when many are used and when some GPIOs are not needed that means that it can be packed tighter together. See the attached screen shot of the chip on the NXP layout.  6-layer board would probably alleviate this.

NXP also has a detailed design guide at https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i-mx-rt-crossover-mcus/i-mx-rt1050-crossover-mcu-with-arm-cortex-m7-core:i.MX-RT1050 "i.MX RT Hardware Development Guide for the MIMXRT1050/MIMXRT1060 Processor" - requires a log-in.

It is undeniable that more board layers and working with finer pitches and smaller holes will increase the price of a PCB and it is up to the designer to decide on such tradeoffs. However, in comparison to a K66, which - if it can be found and purchased at its normal price - tends to be much more expensive than an i.MX RT 10xx - maybe in the order of $10..15 and, coupled with much more peripherals and performance even paying more for a PCB should result in a cheaper (and potentially) better product.

I have also attached a screen shot of one of my designs where I use 77 ports/GPIO plus 1 x USB.

Regards

Mark


42
NXPTM M522XX, KINETIS and i.MX RT / Re: RT1064, boot from SD.
« on: March 08, 2023, 06:31:48 PM »
Hi

If there were no QSPI flash the only loader available is the ROM loader, which can boot from SD cards but is not necessarily a very good choice since SD cards are unreliable in comparison to QSPI flash and if the card fails, is corrupted or is removed the board can't do anything.

It is possible for the uTasker boot loader to also load directly from SD card to RAM or SDRAM but, due to the above, I would never recommend it for an embedded system - plus why use an expensive (heat sensitive) SD card to hold a small program when a cheap ($0.50) QSPI flash can do it better? [Since a 1064 has this inside anyway it would make even less sense]

I don't know why there is a limit in ITC size in the article but that may be the ROM loader's limitation (unless eFUSEs are set possibly to change the configuration, which cannot be changed back again...!). The uTasker loader (running in the first blocks of QSPI flash) is limited to the chip's 512k ITC (since it can dynamically configure this according to the code's requirement) or much larger in SDRAM (or much larger in QSPI flash).

As noted in the article it is cool to boot from an SD card directly (without any need for QSPI flash) but whether it makes real sense in a real -world embedded system is highly unlikely.

Regards

Mark


43
NXPTM M522XX, KINETIS and i.MX RT / Re: RT1064, boot from SD.
« on: March 08, 2023, 02:04:31 PM »
Hi

The standard SD card boot loader method is to have he new image on the card and load it to QSPI flash (and delete the SD card image after successful transfer).
At each subsequent boot there are three possibilities:
- copy the code from encrypted QSPI flash to ITC RAM and run it there (fastest operation)
- copy the code from encrypted QSPI flash to SRAM and run it there (second fastest operation but operation s no longer encrypted since the SDRAM operation can be observed)
- Run the code in place in QSPI Flash (XiP) or XiP-BEE (on the fly decryption). XiP is (depending on caching) up to 20x slower that running from ITC and less deterministic since the speed depends on caching so can change) -  XiP BEE is a bit slower again (about 30% I have heard). When the QSPI Flash in internal to the chip (RT1064) it is protected and possibly there is no advantage of using XiP BEE for code protection.

ITC + DTC is limited to the FlexRAM size of the chip. RT105x/6x have 512k so programs up to about 512k would be possible (as long as data is located in SDRAM or 512k OTCRAM2 (in 106x)

Large QSPI Flash are available so program size shouldn't generally be an issue (except for RT1064 where it is fixed at 4MBytes) and SDRAM loses code protection so is not always the best choice.

Regards

Mark

44
NXPTM M522XX, KINETIS and i.MX RT / Re: uTasker for Kinetis MK64
« on: March 08, 2023, 01:53:40 PM »
Hi

Booting (or boot loading) from an SD card is possible and the card can be used for other storage too.
RT1062s are 0.65mm pitch. Since PCB hole sizes are a little smaller the PCB can be more expensive (about +20%) but the 0.8mm BGA is in fact a more expensive part and they tend to cancel each other out and results in smaller possible boards. Soldering of 0.65mm pitch is no problem since the chips align themselves when the solder is molten so I don't think it is a factor to consider.

Regards

Mark

45
Hi All

Note that the chip shortage has resulted in the uTasker project investing in the following chips, which are reserved for uTasker users and available at reduced prices (in comparison to distributors):

IMXRT1062DVL6B - commercial
IMXRT1062CVL5B  - industrial


These are 10mmx10mm 196 pin BGA with full features (2 x Ethernet, 2 x USB ,1Meg RAM, TFT display interface) and footprint compatible (and code 99% compatible) with i.MX RT 1051/52/61/62 and are useful for porting Kinetis projects to (they can also be used in place of i.MX RT 1064 as long as there is a QSPI flash connected)). With 600MHz zero wait state operation (up to 1.2G instructions per second) they are FAST as well. As well as having very high compatibility with Kinetis the uTasker project makes it simple to port from Kinetis projects and, with the chip stock, can ensure that supplies are immediately available when needed (some parts still have over a year delivery time otherwise).

The small BGA was chosen after experimentation with soldering (also hand soldering) and layout with 4-layer boards. Reference designs and guidance is thus available for those unsure about using BGAs, whereby it can be stated that they are not as difficult to work with as initially feared and result in small, reliable circuity.

There are good stocks available for immediate delivery or reservation, whereby each new project can order/reserve up to 1'200 pieces at the moment. (Quantities of up to 10'000 are possible for immediate delivery but only under exceptional circumstances since it is preferred to supply as many new projects as possible).

Regards

Mark

Pages: 1 2 [3] 4 5 ... 218