Hello,

I'm working on this i2c current sensor that data needs to be send to windows host app. I'm using EFM8UB10 mcu with their VCPxpress usb library (virtual COM). Their forum is scares and mostly useless.
I'm attaching 2 screen shots of data transfers with the same firmware. The issue is that mcu sends bunch of nonsense with the data. Sometimes its fine though and it works for few minutes or after disconnecting and reconnecting the board it will do the same.
Data sheet recommends having ESD protection on the Bus, d+, d- lines which I have.
In some designs is see people use low value resistors as well. Would that correct the issue? Does this look firmware or hardware issue? Tested on few different boards.

 

Neither one looks like proper behavior for a virtual COM port. If I had to guess I would say that resistors have nothing to do with the problem. In fact you have given us very little useful information so the answers reflect that fact.

 

@Papabravo What would you like to know?

Main loop is waiting for current sensor to flag data ready, reads it over i2c and then sends over USB with this:

    sprintf(TX_Packet,"%0.2f",vBus);
             TX_Packet[4] = 0x0A; // Null string
             Block_Write(TX_Packet, InCount, &OutCount);  

             sprintf(TX_Packet,"%0.2f",Amps);
             TX_Packet[4] = 0x0A;  // Null string
             Block_Write(TX_Packet, InCount, &OutCount);

 

How is any of that doing a "receive" function?
How about a schematic diagram?
Do you have some information on the BlockWrite( , , ) function?
Why are you dropping 0x0A (linefeed characters) in TX_Packet[4]?
What is the size of the array TX_Packet[]?
Why do you think what you are providing is sufficient to help you?
Notice all the other folks rushing in to help?

 

I think its firmware because after changing:
lock_Write(TX_Packet, InCount, &OutCount); // Start USB Write
to
lock_Write(TX_Packet, 5, &OutCount); // 5 packets

It doesn't show nonsense but it crashes once a while. Debug shows that's its crashing because its still wants to send a lot of different data:



- I don't really use receive function. Its just sends 2 within screen update. There is something in callback:

#define PACKET_SIZE 64
uint16_t xdata InCount;                   // Holds size of received packet
uint16_t xdata OutCount;                  // Holds size of transmitted packet
uint16_t xdata RX_Packet[PACKET_SIZE];     // Packet received from host
uint16_t xdata TX_Packet[PACKET_SIZE]; // Packet to transmit to host

CPXpress_API_CALLBACK(myAPICallback)
{
   uint32_t INTVAL = Get_Callback_Source();


   if (INTVAL & DEVICE_OPEN)
   {
         Block_Read(RX_Packet, PACKET_SIZE, &InCount);   // Start first USB Read

   }

   if (INTVAL & RX_COMPLETE)                          // USB Read complete
   {
         ProcessData();
         Block_Write(TX_Packet, InCount, &OutCount);     // Start USB Write
   }

   if (INTVAL & TX_COMPLETE)                          // USB Write complete
   {
      Block_Read(RX_Packet, PACKET_SIZE, &InCount);   // Start next USB Read
   }

   if (INTVAL & RX_COMPLETE)                          // USB Read complete
   {
        ProcessData();
        Block_Write(TX_Packet, InCount, &OutCount);     // Start USB Write
   }

}


void ProcessData(){

      if(atoi(RX_Packet) == 4444)  // Read VBus
            {
         sprintf(TX_Packet,"%0.2f",vBus);
            TX_Packet[4] = 0x0A; // Null string
            }
      else if(atoi(RX_Packet) == 4445)  // Read Current
           {
          sprintf(TX_Packet,"%0.2f",Amps);
          TX_Packet[4] = 0x0A; // Null string
           }
      else
            {
          strncpy(TX_Packet,RX_Packet,InCount);
          }
}

But this would randomly crash.

Unfortunately For write block I get only this from library:

int8_t Block_Write(uint8_t* block, uint16_t numBytes, uint16_t* count_ptr) large;

I have 0x0A otherwise usb would crash. I though that's a "end transaction".

Since there are articles about this this specific MCU i figured there might be folks here that know what's up.
Either way you asking about receiving pointed me to packet size and its better. Just still randomly crashing because of the nonsense info.