Messages

61

NXP^TM M522XX, KINETIS and i.MX RT / Re: 1 UDP socket for server and client?

« on: June 29, 2022, 12:50:38 AM »

Neil

If you send a UDP packet to an IP address whose MAC is not known it will cause ARP resolution to be started (and not the UDP frame being sent).

ARP informs the owner task, which can then resend the UDP frame when the MAC address is known:

        case TASK_ARP:
            fnRead(PortIDInternal, ucInputMessage, ucInputMessage[MSG_CONTENT_LENGTH]); // read the message content
            switch (ucInputMessage[0]) {                                 // ARP sends us either ARP resolution success or failed
            case ARP_RESOLUTION_SUCCESS:                                 // IP address has been resolved (repeat UDP frame).
                fnSendUDP(MyUDP_Socket, ucUDP_IP_Address, MY_UDP_PORT, (unsigned char*)&ptrUDP_Frame->tUDP_Header, UDP_BUFFER_SIZE, OWN_TASK);
                break;

            case ARP_RESOLUTION_FAILED:                                  // IP address could not be resolved...
                break;
            }
            break;

See also the UDP thread at https://www.utasker.com/forum/index.php?topic=41.0 which explains it in detail.

Regards

Mark

62

NXP^TM M522XX, KINETIS and i.MX RT / Re: 1 UDP socket for server and client?

« on: June 24, 2022, 01:45:02 PM »

Hi Neil

Only 1 UDP socket is needed.
Transmission can take place at any time on the socket.
The socket call-back is used for reception, which can also happen at any time.

The only thing that changes over time with UDP is related to ARP table entries. If the destination address is in the ARP table transmissions take place immediately and if not ARP first has to resolve it; the cal back informs that the content should be repeated once it has resolved. With time ARP entries time out and this needs to be repeated.

Apart from that detail I don't see that the behavior changes (or failures start occurring) over time so I expect problems are likely to be outside of the UDP functionality.

Regards

Mark

63

utFAT / Re: New SD cards stuck in CARD_BUSY_WAIT

« on: May 23, 2022, 08:24:09 PM »

Hi

SD Cards are used mainly n SDHC/SDIO mode and that will be 99.999% the case when inserting them into pieces of equipment like cameras.

In the past I have hear of batches of card that didn't work normally in SPI mode but worked as expected in SDHC mode.

The last change that I made was 2 years ago in order to ensure that a batch of cards that suddenly used a different version of the specification (I believe in SPI mode) could be handled:

30.04.2020 Add option SUPPORT_SDCARD_V1 to allow V+ SD cards to be used

In that mode there is a command that is not supported and so has to be ignored when it fails but I don't see it to be the same case as yours. If it is not enabled you could however give it a try.

Have you tried the "info" command in the SD card menu? This will show the card's CSD register content which gives some details and may show that there is a difference when compared with the cards that have worked.

The SPI mode was developed about 14 years ago and I don't remember the details of the start and stop bit method that was integrated (or whether anything was not respected in the process) but you are welcome to send me a reference card so that I can investigate if you don't find a solution to get the batch operating.

Regards

Mark

64

utFAT / Re: New SD cards stuck in CARD_BUSY_WAIT

« on: May 20, 2022, 08:20:09 PM »

Hi

During the mounting of the card once of the first things done is to execute the
CMD55
CMD41
sequence.

Typically the first of these take some time to be performed by the SD card it returns its busy state until it has completed and the CMD41 can be continued with.

It is however not normal that the card never returns that it has completed the first command. This also means that this is not something that have been experienced and worked around before.

Is the card being use in SDHC or SPI mode?

Regards

Mark

65

NXP^TM M522XX, KINETIS and i.MX RT / Porting projects to the i.MX RT

« on: May 20, 2022, 08:07:16 PM »

Hi All

Due to the present processor shortage - especially Kinetis family parts - there is a lot of activity porting existing products to be able to run in i.MX RT parts, which tend to be more readily available.

During the transfer of code that has run correctly for years on the Kinetis (Cortex M0+, Cortex M4) there are some initial surprises when it hard faults on the Cortex M7 of the i.MX RT. The Cortex-M7 is very sensitive to alignment and I have found that the GCC compiler with high optimisation often generates code that access them with mis-aligned accesses and cause hard faults.

By reducing the optimisation of the compiler it often goes away and I also find that declaring variables that cause hard faults as volatile stops the compiler optimising and then corrects access alignment - from what I hear I expect you have also identified such.

I had a discussion with Eric Styger here (see discussion at the bottom) https://mcuoneclipse.com/2021/10/12/spilling-the-beans-volatile-qualifier/

where I believe that the use of volatile to solve such things (when they have been correctly understood) is valid. There are arguments about this being the wrong way but - as you can see - I think that it is valid in such cases and that is what I do use. You will find various such work-arounds in the code that were needed for the i.MX RT. For example, new routines
    21.12.2021 Add fnSafeGetBufLittleShort(), fnSafeGetBufLittleLong(), fnSafeGetBufBigShort(), fnSafeGetBufBigLong() {103}
    09.01.2022 Add fnSafePutBufLittleShort(), fnSafePutBufLittleLong(), fnSafePutBufBigShort(), fnSafePutBufBigLong() {104}
are used in some code and drivers to copy buffer content in a safe way.

Usually it is quite obvious that the hard faults are due to the compiler optimising accesses (trying to use 32 bit instead of 8 bit but accessing on unaligned boundaries) by looking at the disassembled code that caused the crash. Then adding the volatile keyword to the variables in question will show that it then doesn't optimise and the code works as expected.

It is a bit of a nuisance (IAR, for example, doesn't have this problem) but when you have experienced and solved it once or twice when moving existing code to the i.MX RT you will find that it is easy to recognise and solve so it is also not that serious.

Regards

Mark

66

NXP^TM M522XX, KINETIS and i.MX RT / Re: CANopen on i.MXRT?

« on: May 17, 2022, 01:46:42 AM »

Hi

It is correct that the driver layer used as reference was from a Coldfire reference but I don't know whether it actually worked since there were some things that didn't match the Coldfire's CAN controller. CO_driver.c is therefore mostly not used since it is HW dependent in its original from and has been made HW independent (but original content retained - commented out - as reference).

Then the interface was reworked to use the uTasker CAN driver interface instead and used in a product (probably about 4 years ago now) on a K64 of K66 .
The Kinetis has FlexCAN (as the Coldfires do/did) and the i.MX RTs also have the same FlexCAN.

If I enable CAN_INTERFACE and

Code: [Select]

SUPPORT_CANopen the project builds for i.MX RTs (although I had to disable two lines in CANopen.c due to a typedef being provided twice):

//typedef unsigned short    MAX_MALLOC;                                    // up to 64k heap chunks
//extern void *uMalloc(MAX_MALLOC);

It may be that that was never needed or became redundant and is only evident when MAX_MALLOC is typedef'ed differently in the application's types.h. My bet is that this is the case and so I will disable these since I don't see that they are needed since there is an include of "config.h" there to access it.

Theoretically this will already run on the i.MX RT since the FlexCAN driver is the only thing that is HW dependent and, since this driver is shared between Kinetis and i.MX RT and assuming it runs on the i.MX RT (which I haven't verified myself just yet - eg. a clock source could be incorrect for speed calculation or there be a register incompatibility somewhere) it will run on any Kinetis, i.MX RT or Coldfire with FlexCAN (although Coldfire is legacy and no longer worked with).

One restriction of the CANopen stack is that it only supports a single instance and so different CANopen instances can't be run on multiple CAN buses..

uCANopenApp.c is used as application interface to the CANopen stack - interfacing with the CANopen.c interface.
If a newer version of CANopenNode is used I expect uCANopenApp.c to remain the same and also CANopen.c to remain the same unless there are changes to the stack's API.
The rest of the newer CANopenNode stack would replace the previous version.

In each of the CANopenNode files I have added:

#include "config.h"

#if defined CAN_INTERFACE && defined SUPPORT_CANopen
...
#endif

which allows them to get their configuration defines from the application configuration rather than needing a configuration header which is not so easily maintained for multiple application use.

Therefore I essentially expect that the 2015 version of CANopenNode should be operational (worst case with a driver / i.MX RT specific correction).
A newer version would need to be integrated but I don't expect any real complications as long as the interface files continue to do their job of keeping the CANopenNode code itself independent to the application's / HW interface.

Regards

Mark

P.S: There is a possibility that I will shortly be using CANopenNode in an i.MX RT based product development and then I would also need to decide whether an upgrade makes sense as part of this work.

67

µTasker general / Re: Can't build simulator app

« on: May 03, 2022, 08:50:43 PM »

Hi

Those two headers are supplied by the compiler library which is presumably either missing can't be found.
It may be something with VS 2022 (I am still using VS 2019) or it may be something missing during its installation - potentially you haven't installed an option that is required since, if i remember correctly, VS 2019 installs the IDE but not all of the language packages and it may be that you need to tell it that you need its C/C++ package which will then deliver the missing libraries.

As a reference I find these two missing files in the folder
C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt

I believe VS 2022 is being used by some and I didn't hear of such issues and therefore I am tending to think that it will be an installation option problem - check out this Microsoft page and verify that the "Desktop development with C++" workload is included.

Good luck

Regards

Mark

68

NXP^TM M522XX, KINETIS and i.MX RT / Re: BOOT_MAIL_BOX location

« on: March 22, 2022, 09:32:19 PM »

Hi Caleb

In fact the boot loader and application can have different memory bank layouts as long as the persistent memory (mail box) is always located at the top of the DTC or the FlexRAM layout is left unchanged.
For this to work (with reconfigured banks) the only requirement is the ordering of the banks - see section RAM and Cache in https://www.utasker.com/docs/iMX/i.MX_RT_1060_uTasker.pdf (although I think that the OCRAM addresses may be incorrect in the image since OCR in the 1062 starts at 0x20280000)

From the diagrams there it is seen that as long as the banks are used in the order IIIIDDD (however many banks are allocated to I) the persistent memory is located at the top of the last D bank.
The absolute address changes of course but the relative address (referenced to the top of D bank memory) remains the same.

fnGetPersistentMemory() returns the memory content relative to the top of memory (it simply assumes that the present stack is there, which would normally be the case).

The boot loader uses the chip's default memory layout and the application can also use it too, as long as its stack pointer is set to the same.

Beware that as banks are reconfigured their absolute addresses change, meaning that if a different strategy were used the absolute address of the boot loader's banks would move around as the application uses different layout and this is the reason for choosing this strategy so that it is (irrespective of how the application configures its bank usage - which can change as a project develops [but respecting the order the banks so that D is always the last]) in fact already solved.

Regards

Mark

69

NXP^TM M522XX, KINETIS and i.MX RT / Re: UDP and TCP server

« on: March 16, 2022, 05:50:46 PM »

Neil

For Telnet there is:
https://www.utasker.com/docs/uTasker/uTaskerTELNET.PDF
(although not a complete description)

For TCP there is:

https://www.utasker.com/forum/index.php?topic=25.0

(which also has examples from Telnet configuration and use)

UDP is so simple it is best to experiment with a simple listener.

Regards

Mark

70

NXP^TM M522XX, KINETIS and i.MX RT / Re: UDP and TCP server

« on: March 16, 2022, 04:12:38 PM »

Hi Neil

Use the HTTP server as reference for a TCP server using simple socket mode.
Use the TELNET server as reference for a TCP server using buffer socket mode.

The only difference between a UDP client and a UDP server is that the USB server is set to listening mode rather than actively connecting to a remote UDP server. The UDP callbacks are otherwise identical. As a server you will generally be listening for data which can arrive at any time and when it does you will receive an appropriate callback event to handle the data - the server will generally make a not of the client's details (eg. its IP address and source port) and can subsequently send data to it in the same way as a client does.

Regards

Mark

71

NXP^TM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).

« on: March 15, 2022, 12:40:10 AM »

Hi Alex

Thanks for the feedback - I am pleased to hear that the binary based technique proved to result in a solution.

As for the OSX slowness - I don't know anything specific except that it may be that it is loading the complete content of the disk (FAT and data?) to the computer so that it has a cache for faster (subsequent) operations. If you have a large card it may take some time as it is not a fast USB connection (a smaller card would, if this is the case, load faster).
You may find settings that control the amount of caching that the computer does (?)

Windows, which I know better, reads in some FAT tables to cache but may do a lot less and so show the disk faster.

However I don't know for sure and a USB analyser that understands MSD would be the best method to see what is happening and whether the delay is due to USB activity needing to first terminate, or not.

Regards

Mark

72

NXP^TM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).

« on: March 13, 2022, 08:10:07 PM »

Hi

The utilities are described in https://www.utasker.com/forum/index.php?topic=1445.0

In your case I would avoid the use of hex files for uploading since binary files are easier. You can convert your two hex files to binary versions using GCC objcpy and then this command can be used

uTaskerCombine main.bin SD.bin 0x33000 fileOut.bin

This will generate a binary output which starts with the content of main.bin and the content of SD.bin at an offset of 0x33000. Any gap between the end of main.bin and the start of SD.bin is filled with 0xff.
The start of this will be located at 0x5080 by the serial loader copy so the start of SD.bin will end up at 0x38080.

Beware that the file is quite large so make sure that the serial loader will accept it and not cut it short (if the max application size is set too small) [this is also relevant for the hex method too].

Regards

Mark

73

NXP^TM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).

« on: March 01, 2022, 07:37:33 PM »

Alex

Are you sure the loader is set up to accept srec files? Normally it accepts binary.
You can use the uTaskerCombine.exe tool to combine two binary files - I don't expect there to be a problem with it accepting that.

Regards

Mark

74

USB / Re: Transition from HS to FS USB

« on: March 01, 2022, 03:24:02 PM »

Hi Alex

I did once run the flash clock of a Kinetis part slightly out of specification (by mistake) and found that it would crash very quickly.

24MHz is within spec. so reducing to 20MHz and finding a difference could mean that the chips are not fully qualified. There is another product that I am involved with that needed to move from a K66 to a K22 due to chip supply problems. In that case it was abandoned since a standard Cortex-M4 instruction caused an unknown instruction hard fault when used by compiled code. Instead a redesign with an i.MX RT part has been used.

Therefore, although I didn't physically test the K22s myself, it is worrying that possible Kinetis parts that are now in circulation may not be up to scratch.

In other products recycled chips are being used (taken from scrapped equipment) - there are some good stocks from companies specialised in recycling which, although already a number of years in service, careful testing has shown that they have proven reliable.

My general advice for all in a difficult situation with Kinetis part supply (where the end is still not in sight) is to seriously consider i.MX RT alternatives since these, although requiring a HW change, is an intelligent long-term investment that has multiple advantages. uTasker users can simply move between Kinetis and i.MX RT since existing products can run on these with very little configuration (in the best case by changing the _KINETIS define to _iMX and adjusting the port muxes to suit).

Regards

Mark

75

USB / Re: Transition from HS to FS USB

« on: February 28, 2022, 04:24:24 PM »

Alex

I understand you can have a hard fault in the following sequence:

1. (Called from USB OTG interrupt and interrupts globally disabled for fnUSB_handle_frame() handling)
                uDisable_Interrupt();                                    // ensure interrupts remain blocked when handling the next possible transmission
                    fnUSB_handle_frame(USB_TX_ACKED, 0, iEndpoint_ref, &usb_hardware); // handle tx ack event
                uEnable_Interrupt();                                     // allow higher priority interrupts again

2.  (when extra data to send is in a linear block)
                FNSEND_USB_DATA((tx_queue->ptrStart + tx_queue->usSent), usDataLength, iEndpoint, ptrUSB_HW); // transmit next buffer
                fnPushLastLength(ptrUsbQueue, usDataLength);             // save last length for use later
                tx_queue->usSent += usDataLength;                        // total frame length in progress

3. Where
        #define FNSEND_USB_DATA(pData, Len, iEndpoint, ptrUSB_HW) *ptrUSB_HW->ptrTxDatBuffer = (unsigned char *)pData; \
                *ptrUSB_HW->ptr_ulUSB_BDControl = (unsigned long)(SET_FRAME_LENGTH(Len) | (OWN | ptrUSB_HW->ptrEndpoint->ulNextTxData0)); \
                _SIM_USB(0, USB_SIM_TX, iEndpoint, ptrUSB_HW); \
                ptrUSB_HW->ptrEndpoint->ulNextTxData0 ^= DATA_1; \
                ptrUSB_HW->ptrEndpoint->ulEndpointSize ^= ALTERNATE_TX_BUFFER

and
the struct in question starts with
typedef struct stUSB_HW
{
    unsigned long  ulRxControl;
    volatile unsigned long *ptr_ulUSB_BDControl;                         // pointer to the presently valid tx buffer descriptor control entry
    USB_END_POINT *ptrEndpoint;
....

and
typedef struct stUSB_END_POINT
{
    unsigned long ulNextRxData0;
    unsigned long ulNextTxData0;
    unsigned long ulEndpointSize;                                        // contains size of endpoint plus some control flags
} USB_END_POINT;


4. From the screen shot it looks like this line can do it:

*ptrUSB_HW->ptr_ulUSB_BDControl = (unsigned long)(SET_FRAME_LENGTH(Len) | (OWN | ptrUSB_HW->ptrEndpoint->ulNextTxData0));

and specifically the
ptrUSB_HW->ptrEndpoint->ulNextTxData0
can fail.

5. The assembler  to this is
ldr r2, [r7, #0]
ldr r2, [r2, #8]
ldr r2, [r2, #4]

ptrUSB_HW is in the register R7 (0x2002ff48), which points to a location at 0x2000ff48 according to the memory window.

r2 is however showing 0x400000, which is the previous content which is typically SET_FRAME_LENGTH(Len) [0x40 << 16], meaning that either this instruction has either not yet been executed or has been overwritten.

If the second assembly instruction is failing (with R2 at 0x400000) it would indeed be a read fr0m 0x400008, which is an invalid address, whereby the instruction's aim is to load the pointer ptrEndpoint so that the following instruction can load the value of ulNextTxData0.

The struct looks to be intact and the location of ptrEndpoint would be OK.

Can you check how uDisable_Interrupt() is set up in your system? I know that you are using FreeRTOs with the USB stack and USB driver and, since it doesn't look possible for r2 to not have the correct value after the first assembler instruction has been executed, I would carefully ensure that no task switching could be taking place (that is, that it is really correctly protected) and the register instance somehow being changed in the process.

Regards

Mark