cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

MiRo_263836
Contributor II

We are trying (in parallel with other actions) to move forward with the TFTP protocol in order to send data to the cloud.

We found a snip:  tftp/ in WICED but we are having issues in sending more than the header...  we did not find any way to insert the "file" data, just the file name and some

other protocol data.

Is there anyone that has been able to use this app and could share some light ?

We selected a "Client" and managed to send a PUT udp packet, with the tftp header, but no data - not sure how to use it to send real data.

We will also try to use tftp for Firmware Upgrade OTA but need to understand it first.

0 Likes
Reply
3 Replies
MuraliR_36
Moderator
Moderator

Hi

Could you let us know on which board you are facing this issue so that we could look into it and help you debug the issue?

Thanks

0 Likes
Reply
MiRo_263836
Contributor II

It is a muRata 1DX module (CYW4343) and an STM32 host.  This is our target hardware which is working fine connecting to the Azure cloud.

0 Likes
Reply
GaAn_541926
New Contributor

Hi MiRo_263836:

I have been trying to understand how the snip TFTP example works too, and I am testing it with the default settings so that the code compiles as a Server.  For testing, I run an external TFTP Clint App, that provides facilities to Send and Receive Files.  From the snip, we see that there are 8 images identified as: FR, DCT, OTA, FS, WIFI, APP0, APP1, and APP2 for the CYW4343-NEB1DX_02 board.  I have success in reading the FR, DCT, and FS images from the snip into my external Client App.  BUT, I have NO success with the other 5 images.  I have narrowed down the problem, when trying to upload APP0 (for example), to a "file size" issue.  When the snip determines that the incoming file size is zero, then it does not continue to accept any incoming data.  From what I can see, the snip goes to the DCT table and gets an expected size of zero, hence does not work correctly.  This snip does not appear to get the file size from the incoming packet, but, it appears that the image needs to be already in the MCU flash, with the correct DCT table information, before it can be re-written with an new APP0 image of exactly the same size.  Is this for real?

I seem to recall reading that for TFTP to work, the file needs to already exist at both ends, and the TFTP is only useful for file replacement.  However, with the Flash allocation for 8 images, it should be possible since the file names are hard-coded into the snip, provided that the Header contains the in-coming size information.

So, I am stuck with the conclusion that this TFTP snip does not work, a situation that is not helped because of the lack of adequate documentation about how the snip works.  I don't think this snip can be useful as a Client because there is no run-time mechanism to request GET or PUT operations.  The code has to be compiled for either GET or PUT as a on-time operation.  Duhh?

Overall, I am very disappointed, and it would be nice if somebody could help get this snip working.

Garry Anderson

0 Likes
Reply