Playing with AT32F437 (3) --- USB OTG peripherals encounter strange practices

RCSN

Playing with AT32F437 (3) --- USB OTG peripherals encounter strange practices [Copy link]

 

 

This post does not make any MCU comparison, but only analyzes the problems encountered when using AT32. However, from my personal experience, it is not as good as ST.

1. When USB BULK transmits a 64-byte integer packet, a ZLP needs to be sent, that is, an empty packet needs to be sent after the transmission is completed. Regardless of the USB rules, and regardless of whether AT32 has ZLP implemented in the hardware, when the bytes to be sent are a 64-byte integer packet, the client is required to send an empty packet in the end. I really feel it is inexplicable and I really don’t understand why this is done. Is it because the underlying interface is not easy to make or the hardware is not easy to make.

2. After the USB BULK transmission is completed, it takes at least 1000 empty instructions to execute. Since the sending interface needs to wait for the USB interrupt flag to complete , I have set the interrupt to the highest level, but it still needs to wait for empty instructions. This kind of interface is inefficient on bare metal. It stands to reason that such a high main frequency should not cause the interrupt response to be so slow. Moreover, the interface should not be left to the customer to wait with empty instructions.

Let's go to the usb_vcp_send_data interface

RCSN

3. When the amount of data is large, it needs to be unpacked and sent, but the strange problem I encountered here is that if the unpacked data is less than 100 bytes, there will be no packet loss. If the unpacked data is more than 100 bytes, there will definitely be packet loss. The author will not compare with ST here, but only the problems encountered in the use of AT32 OTG.

Here we can use to send a 320*240 picture, that is, 320*240*2=153600 bytes. Here we unpack and send each packet with 38400 bytes. According to the manual register definition, the PKTCNT, that is, the number of packets, should be 600, that is, 0x258. The XFERSIZE register should be 38400, that is, 0x9600.

Well, it looks like the registers are assigned correctly.

After clicking send, the registers are empty and the USB interrupt is entered. However, from the serial port assistant, 38400 - 36864 = 1536 bytes are lost.

I thought it was the assistant's problem. I changed to another assistant and it was the same.

The original factory technicians said that they had no problem and that no matter how many packets they sent, it would be fine. I can't do anything about this. My problem is that there is no problem sending small packets, but large packets will definitely be lost. The picture transmission in the previous post shows that each packet is split into 90 bytes and sent, so the display is a little lag.

Also, does anyone have an AT32F415 with OTG? If you have such a board, I can give you an example and test it with 415 to verify my problem. At least in theory, the OTG IP peripherals are the same.

1399866558

Sincere cowhide,

RCSN

1399866558 Published on 2021-12-20 22:33 Sincere cowhide,

Dam?

怀揣少年梦

RCSN published on 2021-12-20 21:21 3. When the amount of data is large, it needs to be unpacked and sent, but the strange problem I encountered here is that if the unpacking is less than 100 bytes, there will be no packet loss. Unpacking...

I also want to get an AT32F437 to play with.

RCSN

Posted by A Young Man with a Dream on 2021-12-21 08:46 I also want to get an AT32F437 to play with

You can apply on the official website

怀揣少年梦

RCSN posted on 2021-12-21 09:52 You can apply on the official website

OK, thanks for your advice

freebsder

Packet loss is by design, no packet loss is a bug

soso

Posted by A Young Man with a Dream on 2021-12-21 08:46 I also want to get an AT32F437 to play with

Looking forward to the evaluation results.

lcofjp

I don't understand USB.

mei4

I have never heard of it, and never thought of it. Very good knowledge, thanks for sharing.

1399866558

RCSN posted on 2021-12-20 23:13 Dam?

le062

Is this how USB drivers are written? Why does it look so much like a serial port?

RCSN

le062 posted on 2021-12-21 21:36 Is this how the USB driver is written? Why does it look so much like a serial port?

It doesn't matter if it is written as a serial port, but the key is that the interface written requires too much operation by the customer. It doesn't matter. Originally, the cdc was intended to be used as a camera data transmission to the PC host computer, but the key is that there will be packet loss. I tested sending a 320*240 picture to the PC in a loop, and there will be packet loss. The packet loss rate is still random.

viphotman

RCSN published on 2021-12-20 21:21 3. When the amount of data is large, it needs to be unpacked and sent, but the strange problem I encountered here is that if the unpacking is less than 100 bytes, there will be no packet loss. Unpacking...

I have a 415 board, how do you test it, please post it;

RCSN

viphotman posted on 2021-12-22 09:31 I have a 415 board, how do you test it, please post it;

The 437 series all use the new library. If you want to use the interface of the old library, it is also OK. They feel the same. Use the cdc device and replace the usb_vcp_send_data sending interface.

The example is to use a 320*240 picture, that is, 320*240*2= 153600 bytes, and send it to the serial port through cdc. See if there are consistent bytes.

Attached is a C array of a picture, just add it to your project.

#include "pic.h"

//这个封装的发送接口
static void cdc_send_buffer(u8 *buf,u32 len)
{
	int32_t _len = len;
	int32_t send_len = 0;
	int32_t inc_len = 0;
	uint8_t send_zero_packet = 0;
	uint32_t timeout = 0;
	while((_len > 0) || (send_zero_packet == 1))
	{
		if(_len > 0)
			send_zero_packet = 1;
		if(_len == 0)
			send_zero_packet = 0;
		timeout = 100000;
		send_len = (_len > 0x9600 ? 0x9600 : _len);
		do
		{
			/* send data to host */
			if(usb_vcp_send_data(&otg_core_struct.dev,&buf[inc_len],send_len) == SUCCESS)
			{
			  break;
			}
		}while(timeout --);
		_len    -= send_len;
		inc_len += send_len;
	}
}

int main(void)
{
   int  count = 0;
/******/
需要进行一些时钟，IO和USB初始化等
******/
 while(1)
{
  for(count = count;count < 10;i++) //循环发10次图片，按理串口助手会收到153600*10 = 1536000字节
  {
    cdc_send_buffer(gImage_pic,(320*240*2))
  }
 
}


} 

viphotman

RCSN published on 2021-12-22 10:10 The 437 series all use the new library. If you use the interface of the old library, it will feel the same. Use the cdc device and replace usb_vcp_send_d ...

No test was successful;

1 New version

The new version AT32F415_Firmware_Library-master and the example BSP\AT32F415_Firmware_Library-master\project\at_start_f415\examples\usb_device\vcp_loopback were burned in, and the micro USB was inserted, but the USB serial port was not recognized on the computer;

2 Old version AT32F4xx_StdPeriph_Lib_V1.3.0

Use CDC_Send_DATA function to transfer data directly.

It only transferred a few KB of data and then stopped;

3 Modify your above function, cdc_send_buffer((uint8_t *)gImage_pic,(320*240*2));

The data transmission stops.

extern uint8_t usb_packet_sent ;
#define USB_TX_LEN_MAX  2000  // 0X9600
static void cdc_send_buffer(u8 *buf,u32 len)
{
	int32_t _len = len;
	int32_t send_len = 0;
	int32_t inc_len = 0;
	uint8_t send_zero_packet = 0;
	uint32_t timeout = 0;
	while((_len > 0) || (send_zero_packet == 1))
	{
		if(_len > 0)
			send_zero_packet = 1;
		if(_len == 0)
			send_zero_packet = 0;
		timeout = 100000;
		send_len = (_len > USB_TX_LEN_MAX ? USB_TX_LEN_MAX : _len);
		do
		{
			/* send data to host */
			//if(usb_vcp_send_data(&otg_core_struct.dev,&buf[inc_len],send_len) == SUCCESS)
			CDC_Send_DATA((uint8_t *)gImage_pic,(320*240*2));
			 if(usb_packet_sent== 0)
			{
			  break;
			}
		}while(timeout --);
		_len    -= send_len;
		inc_len += send_len;
	}
}

//-----------------
static uint16_t CDC_DataTx (void)

...
  USB_DCD_EPT_Tx (&USB_OTG_dev, CDC_IN_EP, &usb_txfifo.fifo[SendPtr] , dwSendLen );
	usb_packet_sent = 0;//modify
  return USB_DEVICE_OK;
}

If you are not familiar with USB, you can see how to modify it;

RCSN

viphotman posted on 2021-12-22 14:23 RCSN posted on 2021-12-22 10:10 The 437 series all use the new library. If you want to use the interface of the old library, you can also use it. The feeling is the same. Use...

1. The new version of the library example uses the vcp_lookback. If it is not recognized, it means that there is a compatibility issue with the new library.

2. The CDC_Send_DATA is estimated to be the maximum uint16 byte length transmission. You cannot directly transmit 320*240*2 bytes. You have to disassemble the packet transmission and see if the returned value is successful.

3. You can change your code like this

4. Do you have QQ? My QQ is 1084534438. We can communicate. The old library seems to be unavailable for download.

extern uint8_t usb_packet_sent ;
#define USB_TX_LEN_MAX  2000  // 0X9600
static void cdc_send_buffer(u8 *buf,u32 len)
{
	int32_t _len = len;
	int32_t send_len = 0;
	int32_t inc_len = 0;
	uint8_t send_zero_packet = 0;
	uint32_t timeout = 0;
	while((_len > 0) || (send_zero_packet == 1))
	{
		if(_len > 0)
			send_zero_packet = 1;
		if(_len == 0)
			send_zero_packet = 0;
		timeout = 100000;
		send_len = (_len > USB_TX_LEN_MAX ? USB_TX_LEN_MAX : _len);
        CDC_Send_DATA(&buf[inc_len],send_len); //最好看下有没有返回值 确保发送成功
		_len    -= send_len;
		inc_len += send_len;
	}
}

viphotman

RCSN published on 2021-12-22 15:27 1. The new version of the library example uses the vcp_lookback. If it is not recognized, it means that the new library has compatibility issues. 2. The CDC_Send...

The new version was tested with a 403A board, v2.0.5

When USB_TX_LEN_MAX is set to 100, data is sometimes lost and sometimes not;

When USB_TX_LEN_MAX is set to 20000, add a delay in the function //delay_ms(3000); then no data is lost; When it is set to 25000, data is also lost;

#define USB_TX_LEN_MAX  100//0X9600  // 0X9600
static void cdc_send_buffer(u8 *buf,u32 len)
{
	int32_t _len = len;
	int32_t send_len = 0;
	int32_t inc_len = 0;
	uint8_t send_zero_packet = 0;
	uint32_t timeout = 0;
	while((_len > 0) || (send_zero_packet == 1))
	{
		if(_len > 0)
			send_zero_packet = 1;
		if(_len == 0)
			send_zero_packet = 0;
		timeout = 0xffffffff;//1000000;
		send_len = (_len > USB_TX_LEN_MAX ? USB_TX_LEN_MAX : _len);
		do
		{
			/* send data to host */
			//if(usb_vcp_send_data(&otg_core_struct.dev,&buf[inc_len],send_len) == SUCCESS)
			if(usb_vcp_send_data(&usb_core_dev,&buf[inc_len],send_len) == SUCCESS)
			{
			  break;
			}
		}while(timeout --);
		_len    -= send_len;
		inc_len += send_len;
		//delay_ms(3000);
	}
}

The old version v1.3.0 was tested with a 415 board;

Modify #define USB_FIFO_MAX 10*1024 //2048

#define USB_TX_LEN_MAX (10*1023), data will not be lost at this time;

But #define USB_TX_LEN_MAX (10*1024)//0X9600 is not accurate at this time, sometimes data is lost, sometimes there is extra data;

extern uint8_t usb_packet_sent ;
#define USB_TX_LEN_MAX  (10*1023)//0X9600
static void cdc_send_buffer(u8 *buf,u32 len)
{
	int32_t _len = len;
	int32_t send_len = 0;
	int32_t inc_len = 0;
	uint8_t send_zero_packet = 0;
	uint32_t timeout = 0;
	while((_len > 0) || (send_zero_packet == 1))
	{
		if(_len > 0)
			send_zero_packet = 1;
		if(_len == 0)
			send_zero_packet = 0;
		timeout = 100000;
		send_len = (_len > USB_TX_LEN_MAX ? USB_TX_LEN_MAX : _len);
        CDC_Send_DATA(&buf[inc_len],send_len); //?????????? ??????
		Delay_ms(400);
		_len    -= send_len;
		inc_len += send_len;
		
	}
}

RCSN

viphotman posted on 2021-12-23 14:39 RCSN posted on 2021-12-22 15:27 1. The new version of the library example uses the vcp_lookback. If it is not recognized, it means that the new inventory...

Thanks for the verification. First, USB transmission requires a delay. Second, there is a probability of packet loss when the amount of data is large.