Anyone have success with CH376 USB flash drive host board?

Log in or register to post comments
Go To Last Post
16 posts / 0 new
Author
Message
Spamiam
Spamiam's picture
Level: Posting Freak
Joined: Mon. Apr 11, 2005
Posts: 1049 View posts
#1
Posted by Spamiam: Sat. Jun 2, 2018 - 01:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I want to write to USB flash drives.  I would love for it to be easy and not put too much load on a M328.  I have a CH376-based board.  It turns out that the factory documentation is rather poor, and it is hard to tell what it takes exactly to get it to work.  I have found some examples on the net, but they are either incomplete, or for interfacing with SPI or parallel.  To reduce pin count, I am looking to use the serial interface.

 

I have had success in recognizing that a flash disk is attached, and I can write valid data to the file.  I can close the file, and a computer can read the file properly.

 

But.... the best I can manage is write 127 bytes at a time.  I THINK the CH376 is capable of at least 255 at a time, and I THINK that you should be able to tell it to expect more than that because I think you can send 2 bytes (16 bit integer) as the number to expect.

 

But when I tell it anything over 127 byes it fails to write.

 

I certainly could break up my data into 127 byte chunks, but that would be more of a PITA.

 

Does anybody have suggestions or a solution?

 

-Tony

Tags:

Tools, Evaluation and Development Kits (AVR-related)
Top
El Tangas
El Tangas's picture
Level: Raving Lunatic
Joined: Thu. Jul 14, 2016
Posts: 2824 View posts
Posted by El Tangas: Tue. Jun 5, 2018 - 10:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suppose you will have to live with that, making it work is already an achievement. I took a look at the datasheet; it's not the worst chenglish I've ever seen, but it's still quite confusing...

Top
Spamiam
Spamiam's picture
Level: Posting Freak
Joined: Mon. Apr 11, 2005
Posts: 1049 View posts
Posted by Spamiam: Tue. Jun 5, 2018 - 11:37 AM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

making it work is already an achievement

 

Well, I started with an example I found online written in 2015, and nothing appears newer that does better.  But that person also was crippled by having to make guesses about what to do.  Other sources discussing parallel interface mention bugs or inconsistencies in it operation.

 

One thing that I found is that I can only tell the CH386 to expect up to 127 bytes.  An 8 bit value is passed so it OUGHT to be able to accept up to 255, but this does not seem to work.  The code that works with a 127 byte transfer fails with even one more byte.  And it seems as if it might have been intended to be able to tell it a 16 bit value of bytes to expect in the transfer because there is another byte (always 0x00) that follows the first, functional, byte.  And the datasheet seems to indicate that it expects a 16 bit value.  Appears to be a bug with how the serial interface works on the chip.

 

I would consider the parallel or SPI interface to the CH376, but for this particular application I need to have as few pins as possible.  I am using it on a M328 (Arduino), and I am already using 16 pins for an external device interface (8 parallel data pins, and 8 other handshaking/signaling pins.  So, I am running out! 

 

I may end up piggybacking the CH376 onto the hardware serial pins, shared with the USB chip for programming the Arduino).  That would free up 2 pins used for software driven serial.

 

I just can't see how this CH376 chip can be a commercial success.  Over many years, there are no resources on the 'net  demonstrating a fully functional interface.  I can only see "examples" that are partially non-functional.  Once I get this project working well then I will post it to github.

 

I am still keeping my eyes and ears open for examples of fully functional CH376 serial interfacing.

 

-Tony

Top
rfdes
rfdes's picture
Level: Hangaround
Joined: Fri. Apr 22, 2005
Posts: 160 View posts
Posted by rfdes: Fri. Jan 11, 2019 - 12:56 AM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi -

I realize that this post is old but I am curious how you  ended up making out with your project. 

A couple of years ago, I designed a commercial boot loader around this chip for the Xmega128 controller using the SPI interface.  I agree that it was a challenge with the datasheet but I worked out my issues and the result turned out just fine.  My only issue as of late is that I have come across certain USB sticks that will not work properly and am challenged as to why. 

 

I would like to correspond regarding the use of this chip and would be willing to share what I know.

take care -

Jim

Top
Simonetta
Simonetta's picture
Level: Raving Lunatic
Joined: Wed. Mar 12, 2003
Posts: 2746 View posts
Location: Portland, Oregon USA
Posted by Simonetta: Fri. Jan 11, 2019 - 02:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PITA is the name of the game in embedded-systems design.

 

If your Mega328 is filled you might be able to use an I2C-to-Input_Output_Ports IC like the Texas Instruments PCF8575 to expand the number of pins available.

 

I haven't heard of this IC before.  There is one module board available on eBay cheaply: https://www.ebay.com/itm/CH376S-...

Is it worth a few dollars to get one and experiment with it? Can you interface to a flash drive with an Arduino using this module board?

Top
djusee
djusee's picture
Level: New Member
Joined: Mon. May 4, 2009
Posts: 5 View posts
Posted by djusee: Mon. Apr 22, 2019 - 08:03 PM (Reply to #5)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi. I wrote a library for this module, feel free to try it out and let me know if you have any problems with it. Thanks

Ch376

Top
BoltSwith
BoltSwith's picture
Level: New Member
Joined: Thu. Oct 10, 2019
Posts: 5 View posts
Posted by BoltSwith: Thu. Oct 10, 2019 - 01:31 PM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Check out the library I wrote for the CH376 IC to work as  USB Host. The library has most if not all the issues you mention solved and has other features. Although it was written using the Atmel Studio 7 IDE in C++. It can be adapted to other IDEs and MCU architectures with little or no modification. Go here to get it and give feedback to help me improve the library's functionality.

https://github.com/BoltSwith/CH376_Library_Cpp

If the facts don't fit the theory, change the facts. ALBERT EINSTEIN

Last Edited: Thu. Oct 10, 2019 - 01:35 PM
Top
BoltSwith
BoltSwith's picture
Level: New Member
Joined: Thu. Oct 10, 2019
Posts: 5 View posts
Posted by BoltSwith: Thu. Oct 10, 2019 - 01:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Spamiam wrote:

making it work is already an achievement

 

Well, I started with an example I found online written in 2015, and nothing appears newer that does better.  But that person also was crippled by having to make guesses about what to do.  Other sources discussing parallel interface mention bugs or inconsistencies in it operation.

 

One thing that I found is that I can only tell the CH386 to expect up to 127 bytes.  An 8 bit value is passed so it OUGHT to be able to accept up to 255, but this does not seem to work.  The code that works with a 127 byte transfer fails with even one more byte.  And it seems as if it might have been intended to be able to tell it a 16 bit value of bytes to expect in the transfer because there is another byte (always 0x00) that follows the first, functional, byte.  And the datasheet seems to indicate that it expects a 16 bit value.  Appears to be a bug with how the serial interface works on the chip.

 

I would consider the parallel or SPI interface to the CH376, but for this particular application I need to have as few pins as possible.  I am using it on a M328 (Arduino), and I am already using 16 pins for an external device interface (8 parallel data pins, and 8 other handshaking/signaling pins.  So, I am running out! 

 

I may end up piggybacking the CH376 onto the hardware serial pins, shared with the USB chip for programming the Arduino).  That would free up 2 pins used for software driven serial.

 

I just can't see how this CH376 chip can be a commercial success.  Over many years, there are no resources on the 'net  demonstrating a fully functional interface.  I can only see "examples" that are partially non-functional.  Once I get this project working well then I will post it to github.

 

I am still keeping my eyes and ears open for examples of fully functional CH376 serial interfacing.

 

-Tony

 

 

Check out the library I wrote for the CH376 IC to work as  USB Host. The library has most if not all the issues you mention solved and has other features. Although it was written using the Atmel Studio 7 IDE in C++. It can be adapted to other IDEs and MCU architectures with little or no modification. Go here to get it and give feedback to help me improve the library's functionality.

https://github.com/BoltSwith/CH376_Library_Cpp

If the facts don't fit the theory, change the facts. ALBERT EINSTEIN

Top
jaccodewijs
jaccodewijs's picture
Level: New Member
Joined: Wed. Oct 30, 2019
Posts: 4 View posts
Posted by jaccodewijs: Wed. Oct 30, 2019 - 01:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been working on a parallel driver for this module to be used in my 65C02 SBC.

I got it all working, up to the point to where, when i write data to the USB thumbdrive, every byte ending with its low nybble 0xF is written as (seemingly) random values.

(so 0x0F, 0x2F, 0xAF, 0xFF, all of it gets written wrongly, all other values are written properly, including bytes with the high nybble set to F (i.e. 0xF0, 0xF3, 0xFA etc)).

 

For the life of me i cannot find out what's wrong here. I tried several different modules, different flashdrives, changed wiring several times, no change at all.

I am wondering if it might be a power issue; either there is a conflict between my WDC65C22 VIA controlling the module on 5V, and the module being 3v3 internally (albeit powered by 5V on the module), or the parallel interface on the chip itself is cripple.

It doesn't seem to be a power consumption issue, as the high nybble values with 0xF work fine.

Also i tested the output pins of the 65C22 for correctness, and that works too.

Even the CMD_CHECK_EXIST command with 0xFF as test byte works fine and responds accordingly, so it is not a wiring error.

 

Anyone out there with the same issue?

Once i get this ironed out, i can clean up and publish my driver here.

 

 

 

Top
djusee
djusee's picture
Level: New Member
Joined: Mon. May 4, 2009
Posts: 5 View posts
Posted by djusee: Wed. Oct 30, 2019 - 01:26 PM (Reply to #9)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I have no experience with parallel communication with this module, but maybe a timing issue?Before sending a command, query the module busy bit. Check the timing diagram, and a logic analyzer would be really helpful in debugging.

Top
jaccodewijs
jaccodewijs's picture
Level: New Member
Joined: Wed. Oct 30, 2019
Posts: 4 View posts
Posted by jaccodewijs: Wed. Oct 30, 2019 - 01:31 PM (Reply to #10)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, that is what I do with all commands that use the #int bit (I am not using the hardware interrupt line but poll the bit in the command register)
Sending commands works perfectly, the issue is only with writing data to the flash drive.

Top
djusee
djusee's picture
Level: New Member
Joined: Mon. May 4, 2009
Posts: 5 View posts
Posted by djusee: Wed. Oct 30, 2019 - 01:42 PM (Reply to #11)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have to poll the busy flag (bit4) also. Writing data to the flash drive can be time consuming for the module, so maybe the module is not ready when the MCU sending out the next byte

Top
jaccodewijs
jaccodewijs's picture
Level: New Member
Joined: Wed. Oct 30, 2019
Posts: 4 View posts
Posted by jaccodewijs: Wed. Oct 30, 2019 - 02:00 PM (Reply to #12)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just tried it, checking the busy flag after each Command and Data write, but it doesn't make a difference unfortunately...

 

I already tried with (long) write pulses, long delays before toggling #CS and #WR pins, thus running the code very slowly.

All of it makes no difference. 0xFF gets written as either 0x60, 0x61 or 0xE1 (seemingly random, but always these values instead of 0xFF)

 

0x0F gets written as 0x01, 0x09 or 0x0B.

 

I am not seeing any correlation, do you?

Last Edited: Wed. Oct 30, 2019 - 02:02 PM
Top
djusee
djusee's picture
Level: New Member
Joined: Mon. May 4, 2009
Posts: 5 View posts
Posted by djusee: Wed. Oct 30, 2019 - 02:28 PM (Reply to #13)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I faced strange problems when i used with long wires or/with breadboard.

Top
jaccodewijs
jaccodewijs's picture
Level: New Member
Joined: Wed. Oct 30, 2019
Posts: 4 View posts
Posted by jaccodewijs: Wed. Oct 30, 2019 - 02:31 PM (Reply to #14)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's intersting.

My ribbon cable connecting the module to the 65C22 is about 15cm long.

Would that qualify as long?

 

I have to try it out with a very short cable then.

Or with a line driver/buffer IC (like 74245 or something)

Top
djusee
djusee's picture
Level: New Member
Joined: Mon. May 4, 2009
Posts: 5 View posts
Posted by djusee: Fri. Dec 13, 2019 - 01:20 AM (Reply to #15)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi jaccodewijs. Has your problem been solved? Have you tried to remove/bypass the 3.3V regulator(plus the resistor for the LED ) and drive it from 5V?Because that what you said, probably is a conflict between them.

Attachment(s): 

Image icon maxIO.jpg
Top