i.MX6 USB Serial Downloader ROM bug?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6 USB Serial Downloader ROM bug?

Jump to solution
1,838 Views
andrewtrotman
Contributor II

Hi,

I'm using the i.MX6Q in USB boot mode and suspect I've found a ROM bug in the implementation of the Serial Download Protocol (SDP).  Someone please correct me where I've gone wrong...

According to the reference manual (section 8.8.2.1.3) the WRITE_FILE command allows me to specify "Valid values for WRITE_FILE COMMAND, ADDRESS, DATA_COUNT".   The issue is with DATA_COUNT.

The USB HID protocol requires me to always send complete packets to the i.MX6Q.  As the output packet size is 1025 bytes (1024 of data preceded by a 0x02 for the Report ID), I must always send 1025 bytes of data even if DATA_COUNT in the SDP is smaller, but this is OK.  The problem I've got is that if I wish to send 2 bytes of data to address 0x00910000 then I must send a 1025 byte packet, and the i.MX6Q ROM then loads all 1024 bytes into memory starting at 0x00910000.  That is, it rounds DATA_COUNT up to whole packet sizes.

I've reproduced this behavior in sb_loader (part of the mfgtools), so it doesn't appear to be a bug of my own.

Have I misunderstood something?  Clearly I can work around this by first reading the contents of the last K of memory I'm going to write into, then writing my own data on top of it, and transmitting it back.  But I'd rather not code up a hack (unless it isn't my bug).

Thanks

Labels (2)
Tags (1)
0 Kudos
Reply
1 Solution
1,084 Views
richard_stulens
NXP Employee
NXP Employee

Andrew,

I'm not very familiar with the boot loader itself, but I am familiar with USB.

I don't think you have to send 1024 bytes.

1024 is the maximum data size of a report descriptor. It is not the Max Packet Size.

MaxPacketSize is the Max size of a single packet. This max size depends on the speed and endpoint type.

For a control endpoint (this is where the report descriptor is transferred), the MaxPacketSize is 64 bytes for high speed, 8, 16 ,32 or 64 bytes for full speed and 8 bytes for low speed.

So, to transfer 1024 bytes on a high-speed control endpoint, you need 1024/64 = 16 packets.

All packets, except the last packet of the transfer must be MaxPacketSize long because a short packet indicates the end of the transfer.

Ex. To transfer 253 bytes you need 4 packets. Three of 64 bytes followed by one with 61 bytes. The 61 byte packet is a short packet and is the last packet of the transfer.

Note that a device reports its MaxPacketSize in the report descriptor. It is the reported size that the host must use for MaxPacketSize.

Regards,

Richard

View solution in original post

0 Kudos
Reply
2 Replies
1,084 Views
YixingKong
Senior Contributor IV

Andrew, have your issues been answered? If yes, please click Correct Answer.

Thanks,

Yixing

0 Kudos
Reply
1,085 Views
richard_stulens
NXP Employee
NXP Employee

Andrew,

I'm not very familiar with the boot loader itself, but I am familiar with USB.

I don't think you have to send 1024 bytes.

1024 is the maximum data size of a report descriptor. It is not the Max Packet Size.

MaxPacketSize is the Max size of a single packet. This max size depends on the speed and endpoint type.

For a control endpoint (this is where the report descriptor is transferred), the MaxPacketSize is 64 bytes for high speed, 8, 16 ,32 or 64 bytes for full speed and 8 bytes for low speed.

So, to transfer 1024 bytes on a high-speed control endpoint, you need 1024/64 = 16 packets.

All packets, except the last packet of the transfer must be MaxPacketSize long because a short packet indicates the end of the transfer.

Ex. To transfer 253 bytes you need 4 packets. Three of 64 bytes followed by one with 61 bytes. The 61 byte packet is a short packet and is the last packet of the transfer.

Note that a device reports its MaxPacketSize in the report descriptor. It is the reported size that the host must use for MaxPacketSize.

Regards,

Richard

0 Kudos
Reply