Messages

16

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

17

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

18

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

19

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

20

µ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

21

µ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

22

µ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

23

µ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

24

µ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

25

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

26

µ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

27

µ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

28

µ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

29

µ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

30

µ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