Recent Posts

Pages: [1] 2 3 ... 10
1
NXPTM M522XX, KINETIS and i.MX RT / Re: 1 UDP socket for server and client?
« Last post by neil on June 29, 2022, 09:50:27 AM »
Hi Mark,
   Many thanks for the reply.

Best Regards
Neil
2
NXPTM M522XX, KINETIS and i.MX RT / Re: 1 UDP socket for server and client?
« Last post by mark 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
3
NXPTM M522XX, KINETIS and i.MX RT / Re: 1 UDP socket for server and client?
« Last post by neil on June 26, 2022, 05:23:58 PM »
Hi Mark
  you have

"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."

Would this involve:
fnDeleteArp();
fnAddARP(ip, mac, ARP_FIXED_IP);

I would know the ip address of the device I am talking to, but is there a way of detecting the mac address after the first connection it makes to the UDP server I have setup in utasker?


Best Regards
Neil
4
NXPTM M522XX, KINETIS and i.MX RT / Re: 1 UDP socket for server and client?
« Last post by neil on June 24, 2022, 01:58:57 PM »
HI Mark,
  Many thanks for your reply.

Best Regards
Neil
5
NXPTM M522XX, KINETIS and i.MX RT / Re: 1 UDP socket for server and client?
« Last post by mark 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

6
NXPTM M522XX, KINETIS and i.MX RT / 1 UDP socket for server and client?
« Last post by neil on June 24, 2022, 11:22:06 AM »
Hi Mark,
  I have 1 socket setup for UDP server and client, is this okay to do, or am I better having 1 socket as a server and one as sending?   My sequences is as follows:

Create 1 UDP socket and setup a listening routine.

Every 10 seconds:

1. Send a request to the device.
2. It then replies with a result.

Very occasionally the device I am talking to stops responding, even though the commands are sent. If I switch on/off my board it all works again. The way around this is I call "fnReleaseUDP_socket" , then re-initialise it again, and all goes well. But now after a good while I get a hardware fault. I thought it might be a memory issue but cant find anything.

So I am not sure if I have to create a socket for sending, and one for receiving? And if releasing and re-initialising the socket can cause an issue?

Best Regards
Neil
7
utFAT / Re: New SD cards stuck in CARD_BUSY_WAIT
« Last post by mark 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



8
utFAT / Re: New SD cards stuck in CARD_BUSY_WAIT
« Last post by timadria on May 23, 2022, 08:45:16 AM »
I indeed use it in SPI mode. The strange thing is that the cards work in my digital camera and laptop.
I've seen in the SD card protocols that a command is always ended with a stop bit. This is not done in your library. I've tested this and then the initialization continuous until the SD_MOUNTING_1 state. Here I get a timeout.

Maybe I can send you one of these cards?
9
utFAT / Re: New SD cards stuck in CARD_BUSY_WAIT
« Last post by mark 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

10
NXPTM M522XX, KINETIS and i.MX RT / Porting projects to the i.MX RT
« Last post by mark 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

Pages: [1] 2 3 ... 10