LAOS Laser

parag0n, please do. I've got no clue how I could debug this otherwise.

Alright, did some testing, trough a serial monitor, listening to the mbed.
I enabled the TFTP_DEBUG and added some printf's of my own.
I'll add some comments between []'s for clarity.

First time I send a file:

onListenUDPSocketEvent  
  state: 0 [listen]
Listen: Incoming file visicut11.lgc on TFTP connection from 10.0.0.10 clientPort 52455

Main::GetFile()

Second time I send a file:

onListenUDPSocketEvent  
  state: 2 [writing]
Listen: Incoming file visicut12.lgc on TFTP connection from 10.0.0.10 clientPort 52456

onListenUDPSocketEvent  
  state: 2
  0x03 [case handling 0x03]
  data: 7 
Read packet 1 with blocksize = 129

Read last block 129

Third time I send a file:

onListenUDPSocketEvent  
  state: 0
Listen: Incoming file visicut13.lgc on TFTP connection from 10.0.0.10 clientPort 60339

Main::GetFile()

onListenUDPSocketEvent  
  state: 2
  0x03  
  char: 7
Read packet 1 with blocksize = 129

Read last block 129

Fourth time I send a file:

onListenUDPSocketEvent  
  state: 0
Listen: Incoming file visicut14.lgc on TFTP connection from 10.0.0.10 clientPort 58713

Main::GetFile()

onListenUDPSocketEvent  
  state: 2
  0x03  
  char: 7
Read packet 1 with blocksize = 129

Read last block 129

So somehow the onListenUDPSocketEvent isn't called and/or there is something wrong with the state. Sadly enough I don't get enough of the system to debug further. Why is it for example in a writing state? Why does it stay there when you send a new file?
How can I simply print what comes in?

Also getting similar issues, making it really hard to use.

Using the MBED compiled firmware seems to mostly solve the issue. Especially the consistent first time send issue seems gone. Awesome side benefit to using the MBED compilation method.