Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
19-01-2014, 11:07 PM,
#1
PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
Hi, as a test i want to run the CDC Single Com Demo which come with Harmony Microchip Platform on the Pinguino PIC32 DIY using MPLAB-X environment.
Originaly this example has been written for an other processor the 32MX795F512L on sk_32mx_usb Microchip demo board.but the USB stack implementation is the same that for 32MX250F128B so with minor changes it should run. I just remapped the led used and the input swith used since mx795 has more ports than mx250f128b. The source compiled in MPLAB-X without errors and i uploaded to the Pinguino PIC32 DIY board with pic32prog using the procedefs.ld modified (read my other post)
But on connection the host does not seem to be able to enumerate the device and connect, even if i see somthing happen

<source>
[ 5793.677056] hub 3-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
[ 5797.873059] hub 3-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
[ 5802.069056] hub 3-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
[ 5804.145064] hub 3-0:1.0: unable to enumerate USB device on port 2
[ 5806.983051] usb 3-2: new low-speed USB device number 34 using ohci_hcd
[ 5807.147048] usb 3-2: device descriptor read/64, error -62
[ 5807.412046] usb 3-2: device descriptor read/64, error -62
[ 5807.670050] usb 3-2: new low-speed USB device number 35 using ohci_hcd
[ 5807.834060] usb 3-2: device descriptor read/64, error -62
[ 5808.099052] usb 3-2: device descriptor read/64, error -62
[ 5808.357073] usb 3-2: new low-speed USB device number 36 using ohci_hcd
[ 5808.761051] usb 3-2: device not accepting address 36, error -62
[ 5808.918053] usb 3-2: new low-speed USB device number 37 using ohci_hcd
[ 5809.322047] usb 3-2: device not accepting address 37, error -62
[ 5809.322069] hub 3-0:1.0: unable to enumerate USB device on port 2
</source>

The cable is not bad for sure since when pushing the bootload combination switch the host recognize the device correctly ad

<source>
[ 6775.908049] usb 3-2: new full-speed USB device number 47 using ohci_hcd
[ 6776.106625] usb 3-2: New USB device found, idVendor=04d8, idProduct=003c
[ 6776.106632] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 6776.106637] usb 3-2: Product: USB HID Bootloader
[ 6776.106642] usb 3-2: Manufacturer: Microchip Technology Inc.
[ 6776.118869] hid-generic 0003:04D8:003C.0007: hiddev0,hidraw1: USB HID v1.11 Device [Microchip Technology Inc. USB HID Bootloader] on usb-0000:00:03.1-2/input0
</source>

I guess that there is some "side-effect" behaviour with the USB bootloader. Do you know any information useful to solve the problem ??

If you want to have a look to the whole project here included there is the tarball.
Enjoy, Fabio.


Attached Files
.zip   TestCDC.zip (Size: 363.79 KB / Downloads: 18)
Reply
20-01-2014, 12:49 AM,
#2
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
I don't think this has anything to do with bootloader. When bootloader jumps to application code, application should be in charge of USB and it can define new descriptors, interfaces, endpoints, restarting USB etc. This is how CDC library works within Pinguino.

There must be something wrong with application code you are running or stack. Bootloader for Pinguino PIC32 is still from Microchip so you are essentialy running two Microchip applications and best place to search for help might be microchip forum.

If not already done so, you might consider downloading latest version of USB stack and this application from Microchip. Problem could be anywhere.
Includes like these are specific to USB stack version you have installed.
app.h:#include "usb/usb_cdc.h"
app.h:#include "usb/usb_device_cdc.h"

There were bugs all over that stack which you can see if you browse Microchip forums, so if you don't have latest one you might be caught in one of them...
Not all processors have same registers for USB and that was one of the bugs I can recall (IPC11 and IPC7) so maybe stack is not handling interrupts like it should hence not proceeding to enumeration phase...

Did you try any other USB demo from Microchip and does it work?
Dreaming in Code...
Reply
20-01-2014, 12:37 PM,
#3
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
I tried to compile only three demos . the CDC Serial Demo that use the USART, CDC Single Com Demo and the Generic HID demo, but never i had the enumeration phase successfull.

Since the USB stack is pretty complex i would like to start from a microchip working example and learn how to use it. I've read that there are bugs in the stack .. for this reason i downloaded the last version of the Harmony Platform which is the v0_70_01b. The Harmony Code configurator engine should insert the right library part of the stack, i hope it to be correct.

I'm currently reading the Harmony Documentation for the USB part so my next step is to get rid of any example and write from scratch a simple test just to pass the enumeration phase, but unfortunately is not an easy task. Should you have any experience in this matter i will ask for help ....

Enjoy, Fabio.

(20-01-2014, 12:49 AM)agolac Wrote: I don't think this has anything to do with bootloader. When bootloader jumps to application code, application should be in charge of USB and it can define new descriptors, interfaces, endpoints, restarting USB etc. This is how CDC library works within Pinguino.

There must be something wrong with application code you are running or stack. Bootloader for Pinguino PIC32 is still from Microchip so you are essentialy running two Microchip applications and best place to search for help might be microchip forum.

If not already done so, you might consider downloading latest version of USB stack and this application from Microchip. Problem could be anywhere.
Includes like these are specific to USB stack version you have installed.
app.h:#include "usb/usb_cdc.h"
app.h:#include "usb/usb_device_cdc.h"

There were bugs all over that stack which you can see if you browse Microchip forums, so if you don't have latest one you might be caught in one of them...
Not all processors have same registers for USB and that was one of the bugs I can recall (IPC11 and IPC7) so maybe stack is not handling interrupts like it should hence not proceeding to enumeration phase...

Did you try any other USB demo from Microchip and does it work?
Reply
20-01-2014, 01:43 PM,
#4
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
I have no direct experience with Harmony but I will download it and try to compile some of the examples on my Pinguino OTG. I only downloaded Microchip Library for applications where the stack is too. This Harmony is in low beta stage looking at version number, so this might too be the reason why stuff are still not working.

I am in process of writing minimalistic USB stack for the new Pinguno PIC32 bootloader so I am quite deep into this matter and can probably help you with pointers. Stack is being written without Microchip libraries, with Pinguino MIPS toolchain but I spent quite some time deciphering how it works in Microchip libraries, so can probably help you there too.

Essentially, Microchip stack can be used in two ways. First is polling where firmware is required to call the stack on every loop and second is interrupt mode. Polling mode can get you in trouble if firmware becomes too complex and does not call stack in proper timing and then USB collapses. Timing is important with USB

For building from scratch, I recommend you read the book from Jan Axelson, USB complete 4th edition, and download USB 2.0 documentation from usb.org to see how USB works. Chapter 9 will be interesting to you. It is a must read if you want to build from scratch, because you will get lost in Microchip code if not knowing why it is written like that. When you start reading you will see a lot of low level stuff like handshake, CRC error checking etc. but most of that stuff is handled directly by USB hardware inside the chip so the complexity of USB shrinks to reasonable limits. It comes down to that firmware, after doing enumeration phase must be able to handle few host requests (and drop others), put data in buffers for sending/receiving.

If you like I can write you here which steps you need to do to pass enumeration process. I can explain stuff like endpoints, buffer descriptor tables, ping pong buffering, transfer types USB has etc... This will give you quick kick start to what is happening behind. ;o)
Dreaming in Code...
Reply
20-01-2014, 07:02 PM,
#5
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
Tnx agolac, i've got the book that is more than 500 pages .. the harmony help is about 4400 pages .. oough ... it a lot of things to read .. however i'll do.
A subtask would be to fix the Microchip example and make it working with pinguino since the example should run out of the box if compiled for the microchip demo board they sell. So the mismatch have to be minimal in my opinion.
I'm doing some experiments and should be nice if you have the same harmony framework to test.
In their help there are three chapter covering USB since they use an abstraction layer concepts to "simplify" (they say) the USB program developments.
There is a USB peripheral library to talk with the hardware in the chip
There is a Driver USB library which use the peripheral library to unify the USB peripheral usage from the application perspective apart the specific processor used. There is an Application USB level library which come with some prebuild kind of application (CDC HID Generic, Audio ..) The reference are

5.1.12 Usb Driver Library
5.6.26 Usb Peripheral Library
5.9.1 Usb Application Library
5.9.4 USB CDC Device Library

Here they explain something of the inside of the USB working... i'm reading...

(20-01-2014, 01:43 PM)agolac Wrote: .......

For building from scratch, I recommend you read the book from Jan Axelson, USB complete 4th edition, and download USB 2.0 documentation from usb.org to see how USB works. Chapter 9 will be interesting to you. It is a must read if you want to build from scratch, because you will get lost in Microchip code if not knowing why it is written like that. When you start reading you will see a lot of low level stuff like handshake, CRC error checking etc. but most of that stuff is handled directly by USB hardware inside the chip so the complexity of USB shrinks to reasonable limits. It comes down to that firmware, after doing enumeration phase must be able to handle few host requests (and drop others), put data in buffers for sending/receiving.

If you like I can write you here which steps you need to do to pass enumeration process. I can explain stuff like endpoints, buffer descriptor tables, ping pong buffering, transfer types USB has etc... This will give you quick kick start to what is happening behind. ;o)
Reply
20-01-2014, 09:21 PM, (This post was last modified: 20-01-2014, 09:34 PM by agolac.)
#6
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
Did you check your configuration words for your board? I quickly looked at Microchip and it says frequency for this processor is 50 MHz, and Pinguno board you built is using it with 40 Mhz. USB must be 48 Mhz but it is derived from primary oscillator. Maybe Microchip demo is setup from 50 MHz as a base for divider? Actualy you said app was meant for other board, so clock might be off more. Check it out...just a thought
Dreaming in Code...
Reply
20-01-2014, 10:10 PM,
#7
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
My config setting are
<quote>
#pragma config POSCMOD = HS

#pragma config FNOSC = PRIPLL
#pragma config FPLLIDIV = DIV_2
#pragma config FPLLMUL = MUL_20
#pragma config FPLLODIV = DIV_2
#pragma config OSCIOFNC = ON

#pragma config FWDTEN = OFF
#pragma config FPBDIV = DIV_2

#pragma config FCKSM = CSECME

#pragma config UPLLEN = ON
#pragma config UPLLIDIV = DIV_2
</quote>

The 8 Mhz XTAL is first divided by 2 then multiplied for 20 and divided again by 2 so the
System Clock is 40 Mhz and the Peripheral clock is 20 Mhz
The Usb clock is 8 Mhz divided by 2 the internally multiplied by 12 hence is 48 Mhz.

Fabio...

(20-01-2014, 09:21 PM)agolac Wrote: Did you check your configuration words for your board? I quickly looked at Microchip and it says frequency for this processor is 50 MHz, and Pinguno board you built is using it with 40 Mhz. USB must be 48 Mhz but it is derived from primary oscillator. Maybe Microchip demo is setup from 50 MHz as a base for divider? Actualy you said app was meant for other board, so clock might be off more. Check it out...just a thought
Reply
20-01-2014, 10:41 PM, (This post was last modified: 20-01-2014, 11:35 PM by agolac.)
#8
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
Yep, looking good. Actually like you said for USB, primary 8 Mhz xtal is only relevant because it is divided directly from it with UPLLIDIV = DIV_2 and then internaly multiplied. So, no problem there...Shy

I'm installing Harmony now, so I'll soon know how it runs on my Pinguino OTG board. Will let you know Big Grin

Ah, great, immediate collapse with bunch of compile errors for 440F256H chip.
Oh, dear Microchip Dodgy

http://www.microchip.com/forums/m768232-print.aspx

The issue with the usb_p32mx440hf256h.h will be fixed in the next release of the Harmony.
..
..
Dreaming in Code...
Reply
21-01-2014, 12:22 AM,
#9
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
Yeep. This harmony is deeply troubled library in early beta stage. I fixed few errors and another dozen emerges, at least for 440MX256H. Bunch of stuff is missing from its header files which throw errors. I'm done with it until more stable release comes out. Good luck ;o)
Dreaming in Code...
Reply
21-01-2014, 02:13 PM,
#10
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
...oohhh ... lerning USB with a troubled early beta library is a pretty weird thing to do .. since i dont know if i'm wrong or is the library that is fault ... however i've done some experiments that exploit some other strange things .. i will came later with details

:-) Fabio

(21-01-2014, 12:22 AM)agolac Wrote: Yeep. This harmony is deeply troubled library in early beta stage. I fixed few errors and another dozen emerges, at least for 440MX256H. Bunch of stuff is missing from its header files which throw errors. I'm done with it until more stable release comes out. Good luck ;o)
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)