Missing bytes when receiving from UART2 and writing to flash


#1

Hi everybody,

I am using Uart2 to receive lots of data (e.g. 34kBytes) which is just dumped to the port. I would assume that when I enable hardware handshaking with

AT+IFC=2,2

that I should not loose data when I am sending from a terminal emulator program (I tried Hyperterm and Tera Term) which also has hardware handshaking enabled.

What I have seen is that 70 to 400 bytes are missing when I write 512 bytes and then read 512 bytes to/from flash using adl_flhWrite() and adl_flhRead() after every 512 bytes received.

Most of the tests I ran with port speed 115200, but I have confirmed that data is also lost when using 19200 or 9600 baud. So I guess the system is too busy writing flash and not necessarily too slow.

If I remove the flash access from the code, the number of bytes will be as expected.

How is it possible that flash writing will miss data on the port??? Is there anything I could do except implementing a protocol which sends only small packets and waits for ACKs?

Best Regards,
Jan


#2

Hello,

From what you describe it sounds very much that the OpenAT flash writing routines takes too much time (and unfortunately, this is not too unusual…) and that the flash writing have higher priority than processing data from UART to OpenAT application.

But its strange that the flow control does not seem to work as it should. :confused:

[color=red]Question: Can you see any activity on the RTS/CTS signals when transmitting the data to the module?

If you have enough RAM space, you could try to buffer everything and then write it to flash.

/Snoooze


#3

Thank you for your quick answer! We haven’t looked at the signals yet…
We will also try to put a switch into the RTS line for `manual´ flow control.

Do you know, if there is a function that returns how much memory is available? In the final program the data may be up to 48kBytes. In a B-memroy type there should be 128k minus about 40kB for TCP/IP minus 48kB for serial data buffer minus stack leaves us less than 38kB… I have no idea how much our application needs for during normal operation and how much at max. And since we have quite some static variables because of problems with edLib and dynamic memory, I really don’t know how much is actually left… I think it would be too optimistic to be sure 48k for buffer can be allocated when it is needed… :frowning:

Best Regards,
Jan


#4

Hello [color=blue]jan

You can check all allocated memory sizes in the map file “m” in the /out directory after building for target. Of course this is only the static memory but it should give you a hint of how much more you can play with.

I don’t know of any API routine to check how much memory that is free but you should be able to keep track of this yourself when you know how much memory thats statically allocated. The dynamic allocation of memory is of course also dependant on how the memory manager works (memory fragmentation etc…) but I dont know how the Wavecom memory manager works in detail.

/Snoooze