This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Chronos Access Point USBCDC_receiveData() does not read data correctly.

Other Parts Discussed in Thread: SIMPLICITI

Hello!

I am trying to modify the command chain of the Chronos application. When starting up the simpliciti stack one needs to send 0xFF 0x07 0x03 bytes to access point. With that mindset I have had the stuff up and running well. Now I have set up the clock with millisecond precision on the end device, which has time_t like second counter and millisecond counter.
Now I would like to send the time_t value from PC via AP to ED with the start simpliciti command, copy that to a buffer in cmdHandler.c and later send it to the end device when it asks for it.
Theoretically the command should be then 0xFF 0x07 0x07 + time_t.
It does not succeed, because somehow the access point is fixed on a 3 byte value ?!
I carried through thorough debugging and I can see that
in USB_Handler_v() the line  bytesReceived = USBCDC_bytesInUSBBuffer(0); is correct that means the bytesReceived == 7.
Everything is okay, now I pursue to read the data. 
uint8_t status = USBCDC_receiveData(&usb_buffer[usb_bufferIndex], bytesReceived, 0);
and in the buffer I get 0xFF 0x07 0x03 0xFD 0xFD 0xFD 0xFD 0x00 0x00....
So I can conclude that it reads 7 bytes. The time_t part of it is corrupted with the values 0xFDs and the length byte is 0x03. This is mysteric. Since the code in USBCDC_receiveData() readability is the same as chinese, I cannot find out where is it being corrupted. The USBCDC_receiveData() part of the logic does not have a clue about Chronos protocol etc...

Thanks in advance!

  • usb_buffer has 0x00 values before the reading operation. This happens even if I send for example 10 bytes of 0xAA, the buffer still has the same values 0xFF 0x07 0x03 0xFD 0xFD 0xFD 0xFD, but with a difference that 10 bytes is being read and all the slots up to [9] have value decimal 171 in it. 
    This gets more and more mysterious how... Nothing is touching the usb_buffer besides usb_decode() but that is being called after USBCDC_receiveData()!

  • Seems like the problem was still on the application side.
    Although I used the same WIN APIs and I had the exactly same COM port setup and parameters except the overlapped functionality, it did not work. I copied the BM_Driver.h and .cpp files to my project and now the stuff works as expected. I do not want to believe that the overlapped was the case, but who knows...

**Attention** This is a public forum