RTOS/TM4C129XNCZAD: NDK unicast

Mohammed Fawzy

Expert 1905 points

Part Number: TM4C129XNCZAD

Tool/software: TI-RTOS

Hello,

I'm using

- CCS Version: 6.1.0.00104,

- TIRTOS: tirtos_tivac_2_16_01_14,

- xdctools_3_32_01_22_core

i have many tasks in my projects, and i'm following uni-casting technique to forward some IP packets over UDP socket, but if i send some packets to multiple targets successively, i will get error (55 = No buffer space available) after the 7th target which indicates that there is no available buffer and because i'm limited in my buffer size so i added a delay between transmissions to the targets up to 100 milliseconds which should be significant but it didn't help and i'm still getting the same error.

my question is:

- did i miss something with the other tasks priorities compared to the NDK tasks that cause the IP packets to be delayed that much such that 100ms is n't that enough?

- for confirmation how the NDK buffer can be increased to reduce the effect of error (55)?

Thanks,

Mohammed Fawzy

over 8 years ago

0 Alan DeMars over 8 years ago

TI__Mastermind 30830 points

I'm digging into this now and will get back to you ASAP when I have questions or answers.

Alan

0 Alan DeMars over 8 years ago in reply to Alan DeMars

TI__Mastermind 30830 points

On the surface of it, it appears that UDP packets aren't exiting the ethernet interface. DHCP uses UDP to obtain an IP address so if you're successfully using DHCP then we can rule out a fundamental issue with UDP. Can you confirm with wireshark that the 6 unicast UDP packets were successfully transmitted on the ethernet?

Alan

0 Mohammed Fawzy over 8 years ago in reply to Alan DeMars

Expert 1905 points

your guess is somehow correct, such that couple of the packets reach the destinations while other aren't, so where is the problem. why the rest of packets are stuck? is it something which is related to the other task priorities?

0 Alan DeMars over 8 years ago in reply to Mohammed Fawzy

TI__Mastermind 30830 points

Its probable that the length of the buffer being sent in your 7th "sendto" call exceeds the max alloc size within the NDK., which is approximately 3k bytes.

This issue has been uncovered and discussed before. See point #3 in the post below for reference.

https://e2e.ti.com/support/embedded/tirtos/f/355/p/372023/1314892#1314892

Alan

0 Mohammed Fawzy over 8 years ago in reply to Alan DeMars

Expert 1905 points

the post dosn't describe the same problem for the following reasons:
- my packet length is 32 bytes
- after doing some debugging, i found that the problem raised starting from PBMQ_deq because there is no pools are available.
and this is why i added 100 ms between each sendto because i was afraid that the sendto invoking rate was larger than the transmission rate. but 100ms didn't solve my problem.
so the problem now in keeping the packets without being transmitted in the ethernet level, so please advice. especially that the time is an issue for me.

0 Alan DeMars over 8 years ago in reply to Mohammed Fawzy

TI__Mastermind 30830 points

From the wireshark traces, can you tell if all of the packets that were sent to "sendto" have actually been transmitted? I'm wondering if the problem is that PBMs haven't been restored to the PBM pool because the packets haven't been transmitted or if the thread that restores the PBMs to the pool after transmission is getting starved.

0 Mohammed Fawzy over 8 years ago in reply to Alan DeMars

Expert 1905 points

actually, i noticed that if i'm trying to send to an IP that isn't exist on my network between my target list. so it seems that if the target isn't available on the network, the packet won't be sent out and even the successive packets for the available targets won't pass through because there is no polls are avaliable, so what do you think?

0 Mohammed Fawzy over 8 years ago in reply to Mohammed Fawzy

Expert 1905 points

Hello,

any updates!

Thanks

Processors

Processors forum

RTOS/TM4C129XNCZAD: NDK unicast