Messages

31

µ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

32

NXP^TM M522XX, KINETIS and i.MX RT / Re: uTasker v2.0.0 doesn't compile on MCUXpresso v11.5.0 (.text LMA overlaps)

« on: August 04, 2023, 12:21:01 PM »

Please see thsi thread too:
https://www.utasker.com/forum/index.php?topic=2164.0

33

µTasker general / Re: SNMP Traps not sending timely and/or locking up, appears to be ARP problem

« on: August 03, 2023, 09:18:59 PM »

I corrected the double "defined" in the previous post (which was of course incorrect).
Regards
Mark

34

µTasker general / Re: SNMP Traps not sending timely and/or locking up, appears to be ARP problem

« on: August 02, 2023, 12:27:06 PM »

Hi Ray

    #if IP_INTERFACE_COUNT > 1 || IP_NETWORK_COUNT > 1                   // {74}
        #define _TCP_SOCKET_MASK_ASSIGN(uSocket)  (uSocket &= (SOCKET_NUMBER_MASK))
        #define _TCP_SOCKET_MASK(uSocket)         (USOCKET)((uSocket) & (SOCKET_NUMBER_MASK))
        #define _UDP_SOCKET_MASK_ASSIGN(uSocket)  (uSocket &= (SOCKET_NUMBER_MASK))
        #define _UDP_SOCKET_MASK(uSocket)         (USOCKET)((uSocket) & (SOCKET_NUMBER_MASK))
    #else
        #define _TCP_SOCKET_MASK_ASSIGN(uSocket)
        #define _TCP_SOCKET_MASK(uSocket)         (uSocket)
        #define _UDP_SOCKET_MASK_ASSIGN(uSocket)
        #define _UDP_SOCKET_MASK(uSocket)         (uSocket)
    #endif

When used in a single network/single interface environment the masks become dummy.
However I see that when SNMP is used a further USER_INFO_MASK field is used (in order to control multiple SNMP managers).
My suggestion is that the use of the mask for UDP sockets (not TCP sockets) be forced with:

    #if ((IP_INTERFACE_COUNT > 1) || (IP_NETWORK_COUNT > 1))             // {74}
        #define _TCP_SOCKET_MASK_ASSIGN(uSocket)  (uSocket &= (SOCKET_NUMBER_MASK))
        #define _TCP_SOCKET_MASK(uSocket)         (USOCKET)((uSocket) & (SOCKET_NUMBER_MASK))
        #define _UDP_SOCKET_MASK_ASSIGN(uSocket)  (uSocket &= (SOCKET_NUMBER_MASK))
        #define _UDP_SOCKET_MASK(uSocket)         (USOCKET)((uSocket) & (SOCKET_NUMBER_MASK))
    #else
        #define _TCP_SOCKET_MASK_ASSIGN(uSocket)
        #define _TCP_SOCKET_MASK(uSocket)         (uSocket)
        #if defined SER_INFO_MASK
            #define _UDP_SOCKET_MASK_ASSIGN(uSocket)  (uSocket &= (SOCKET_NUMBER_MASK))
            #define _UDP_SOCKET_MASK(uSocket)         (USOCKET)((uSocket) & (SOCKET_NUMBER_MASK))
        #else
            #define _UDP_SOCKET_MASK_ASSIGN(uSocket)
            #define _UDP_SOCKET_MASK(uSocket)     (uSocket)
        #endif
    #endif
#endif

Thanks for identifying the issue - presumably I always had a mult-network environment when working with SNMP to have missed this.

Regards

Mark

35

µTasker general / Re: SNMP Traps not sending timely and/or locking up, appears to be ARP problem

« on: July 27, 2023, 10:51:07 PM »

Ray

Check that TASK_SNMP is in ctNodes[] in TaskConfig.h

In addition, make sure that you have no new task with the same name.

    {"MsnMp",     fnSNMP,       SMALL_QUEUE, (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_STOP},

#define TASK_SNMP               'n'                                      // SnMP protocol task

This looks wrong - TASK_SNMP should match the first character of the task's string name.

Try with

    {"nsnMp",     fnSNMP,       SMALL_QUEUE, (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_STOP},

instead!

Regards

Mark

36

µTasker general / Re: SNMP Traps not sending timely and/or locking up, appears to be ARP problem

« on: July 27, 2023, 02:24:34 PM »

Hi Ray

In ip.c I see that only ARPs directed directly to your IP address are entered so I am not sure that it is appropriate to remove that when ARP_IGNORE_FOREIGN_ENTRIES is enabled.
However the ARP table should not be critical since the worst thing that can happen is that a resolution needs to first be performed when the destination is not yet known.
You can also increase the size of the ARP table so that entries don't need to be deleted when new ones are entere but there is not space for all.

Regards

Mark

37

µTasker general / Re: SNMP Traps not sending timely and/or locking up, appears to be ARP problem

« on: July 26, 2023, 11:30:18 AM »

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

38

NXP^TM 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.

39

NXP^TM 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

40

ST^TM STM32 and STR91XF / Re: how to configure SPI pins for bootloading (STM32F405)

« on: June 14, 2023, 10:30:40 PM »

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

41

NXP^TM M522XX, KINETIS and i.MX RT / Re: Kinetis K60 Ethernet phy MDIO comm. problem

« on: May 31, 2023, 10:41:46 PM »

Hi Ray

I am please that you managed to catch the issue.

Regards

Mark

42

NXP^TM M522XX, KINETIS and i.MX RT / Re: Kinetis K60 Ethernet phy MDIO comm. problem

« on: May 31, 2023, 08:01:57 PM »

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

43

NXP^TM M522XX, KINETIS and i.MX RT / Re: Kinetis K60 Ethernet phy MDIO comm. problem

« on: May 30, 2023, 10:25:20 PM »

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

44

µTasker general / Re: How to identify code that causes a SW watchdog reset

« on: April 29, 2023, 01:45:48 PM »

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

45

NXP^TM M522XX, KINETIS and i.MX RT / Re: i.MX RT Linker Script files for compatibility with MCUXpresso V11.5 and above

« on: April 24, 2023, 09:36:28 AM »

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