use Device BGM121 ;
SDK Ver 2.9.2 ;
used: Sample source code: SPP_example_SDK - 2.7.0 - v 2. Zip
Use RS232_IC with VCC = 3.3V.
If the part uses 0 / 3V3 signal levels then it is most probably fine.
To disable VCOM, simply locate the following line in hal-config.h:
#define HAL_VCOM_ENABLE (1)
Change the value from 1 to 0 and rebuild the project, that's all you need.
Using PA2 (TXD), PA1 (RXD) of CHIP with RS232 BUFF IC,
What kind of external USB-to-UART converter are you using? Make sure it uses CMOS signaling (3V). The actual RS232 standard uses different voltage levels.
########## To elucidate the problem, When I tried a new test I found a new problem. ###########
It's really difficult to debug this sort of issues remotely. I have personally tested transferring large amounts of data (megabytes) between two kits, without any lost data. It required modifying the retargetserial.c code, to preven the RAM buffer overflowing. This modification is NOT included in the original example code that is attached to the knowledgebase article.
I think you should next try to identify where exactly the data is lost. I recommend counting transmitted bytes and packets both at the sender and receiver. Run the test for some time (10s or 30s, or whatever is needed to reproduce the error). Then compare the counters on sender/receiver. This could help identify if the bytes are lost on the sender side or receiver side.
Next thing I would check is the flow control settings of the development kit (WSTK). This can be done in Simplicity Studio, see attached pictures:
Step1: right click the kit in Studio main view and select Launch Console...
Step 2: Open the Admin console and check the VCOM settings:
Hit enter in admin console and you should see the WSTK> prompt. You can then check the VCOM settings with command
To turn on RTS/CTS handshaking, use command:
serial vcom config handshake rtscts
You can then run command serial vcom again to make sure the settings are correct.
In the above test,
Even when the received data is lost,
UartReviceBuffOverCnt remains 0.
UartReviceBuffOverCnt is output to the monitor.
In conclusion, "RX BUFF OVER" does not.
What are the other causes?
To answer your additional questions:
1) I have personally tested large data transfers using VCOM and haven't seen problems with the VCOM itself. If your application handles the buffer overflow correctly then there should be no data lost at all.
2) The hacks that you have made to the serialtarget.c do not seem like a good way to handle this situation, so I'm not surprised that you are still losing data.
I don't see what is the point of this lengthy code snippet that you posted. Seems like you have removed the overflow checking from the original retargetserial.c driver which seems quite risky.
Processes UART data received by interrupt with 10 mSec interval timer.
I think that it will not fill up with 256 Byte RSBuff.
The overflow can be easily detected in the driver code, so instead of just "hoping that it will not fail" why not implement overflow checking in the driver?
One note about your modified code is also that it only works for fixed size buffer 256 bytes. If you wanted to use different size (like 200 bytes or 512 bytes) the code no longer works.
I am using VCOM
For VCOM USB <====> UART conversion
Is there a problem?