Building WBW firmware under Linux

USB PICs and the UBW

Moderator: phalanx

Building WBW firmware under Linux

Postby rickbronson » Sat Sep 22, 2007 8:21 am

Hi,

Has anyone built the UBW firmware under Linux using sdcc? I'm willing to give it a try if it hasn't been done. My goal would be to have one software set that's compilable by either MPLAB or sdcc. The only difference is that sdcc would use a Makefile.

Should I use the latest release code (D v1.4.2) or use the unreleased v1.4.3?

Thanks for any input/help.

Rick
rickbronson
 
Posts: 18
Joined: Thu Sep 20, 2007 3:18 pm

Postby EmbeddedMan » Sat Sep 22, 2007 11:59 am

Rick,

I would use the current 1.4.2 release of the code. If you can get it to work and post your changes, then everyone can benefit.

I don't know of anyone who's build the firmware under Linux yet. Go blaze a trail!

*Brian
User avatar
EmbeddedMan
Support Volunteer
 
Posts: 1362
Joined: Sun Mar 05, 2006 9:23 pm

Postby rickbronson » Mon Sep 24, 2007 4:47 pm

I got it built up using sdcc and now I'm trying to build it using MPLAB but I get a message "unable to load workspace becasue the format of the workspace has changed" when I open the project file. Is this because I'm using the wrong version of MPLAB.

What version of MPLAB and C18 do I need to use?

Rick
rickbronson
 
Posts: 18
Joined: Thu Sep 20, 2007 3:18 pm

Postby EmbeddedMan » Tue Sep 25, 2007 5:30 am

Rick,

The project should build fine with the latest version of MPLAB - 7.62. I also use C18 v3.12 student edition.

*Brian
User avatar
EmbeddedMan
Support Volunteer
 
Posts: 1362
Joined: Sun Mar 05, 2006 9:23 pm

Postby rickbronson » Wed Sep 26, 2007 7:35 am

Thanks for the tip on versions. Once I got those newer versions,
things started working.
I'm heading on vacation for a week but if anyone feels so inclined, I've got a version that compiles but the usb doesn't seem to work quite right. Just to let you know, I did compile the "Demo02" code and that worked under sdcc. Anyway, here is the code if anyone feels so inclined

http://www.efn.org/~rick/pub/D_143.sdcc.tar.bz2

Any input would be greatly appreciated.

Rick
rickbronson
 
Posts: 18
Joined: Thu Sep 20, 2007 3:18 pm

Postby polly » Thu Oct 04, 2007 8:37 am

hello rick,
Hopefully you didn't fritter away your vacation time lurking in hotel lobby hotspots ! ..
I gave your code a whirl, maybe we have different sdcc header files, I had
to change ACTVIE and ACTVIF in usbdriver.c in a couple of places to
ACTIVIE and ACTIVIF and then I got a clean build but, as you, was unable to see a good usb hookup.
I'd gone through the same exercise a few months back and got similar results, /var/log/messages shows: Oct 4 11:28:01 abby kernel: usb 2-2: new full speed USB device using ohci_hcd and address 14
Oct 4 11:28:01 abby kernel: usb 2-2: device descriptor read/64, error -110
Oct 4 11:28:01 abby kernel: usb 2-2: device descriptor read/64, error -110
Oct 4 11:28:02 abby kernel: usb 2-2: new full speed USB device using ohci_hcd and address 15
Oct 4 11:28:02 abby kernel: usb 2-2: device descriptor read/64, error -110
Oct 4 11:28:02 abby kernel: usb 2-2: device descriptor read/64, error -110
Oct 4 11:28:02 abby kernel: usb 2-2: new full speed USB device using ohci_hcd and address 16
Oct 4 11:28:02 abby kernel: usb 2-2: device not accepting address 16, error -110
Oct 4 11:28:03 abby kernel: usb 2-2: new full speed USB device using ohci_hcd and address 17
Oct 4 11:28:03 abby kernel: usb 2-2: device not accepting address 17, error -110

which is similar to what I saw before. My 'VUsbReg Led' indicates the device
stays connected at some level, my suspicion is the descriptors are not right somehow. Maybe I'll do a diff on the hexfiles for clues. Best, p
<=>
polly
 
Posts: 190
Joined: Mon Jun 05, 2006 2:10 pm

Postby rickbronson » Tue Oct 09, 2007 7:20 am

Polly,

Thanks for trying the code! Hopefully this week I'll get a chance to try it again. I thing you're right about the problem most likely in the descriptor code.

Rick
rickbronson
 
Posts: 18
Joined: Thu Sep 20, 2007 3:18 pm

Postby polly » Wed Oct 10, 2007 8:40 am

Still hacking away at it. I managed to shoehorn my UART-enabled app
in place of user.c, poking around via the UART, which involves debugging
on one of my few remaining boxes with a serial port. It would be reeely neat
to have a UBW cicuit board with USB sockets for both the PIC's USB port and
a USB-Serial chip attached to the UART ... hint hint, Brian !
<=>
polly
 
Posts: 190
Joined: Mon Jun 05, 2006 2:10 pm

Postby EmbeddedMan » Wed Oct 10, 2007 10:21 am

polly,


Yah, you're right. That would be neat. What would be neater would be to have a little hub right on the board, so, with 1 USB connection you could get a USB connection to the PIC, and a USB->Serial (FTDI or whatever) that you could jumper to the PIC or use as a straight up serial port (i.e. level translators). That certainly would be cool.

You're welcome to take a crack at it! <wink>

If your 'serial' connection inside the PIC (via USB) is working, then to me that's the easiest (and certainly cheapest) way to debug. But until you get there, a real hardware port _would_ be nice.

*Brian
User avatar
EmbeddedMan
Support Volunteer
 
Posts: 1362
Joined: Sun Mar 05, 2006 9:23 pm

Postby polly » Wed Oct 10, 2007 1:19 pm

At my learning curve it'll be 'dodo', not 'eagle' . Suppose I could get uncheap and buy Sparkfun's FTDI on a stick....

Rick, the device desriptor looks empty, not in the hex but via UART readback, still peeking.
<=>
polly
 
Posts: 190
Joined: Mon Jun 05, 2006 2:10 pm

Postby polly » Wed Oct 10, 2007 1:29 pm

Probably my fault, not reading from program space .. ( stoopid Harvard Architecture.. )
<=>
polly
 
Posts: 190
Joined: Mon Jun 05, 2006 2:10 pm

Postby rickbronson » Thu Oct 11, 2007 9:00 am

Well, after two days of frantic poking, I'm about ready to through the towel in ;-) Here is what I did:

1. Wire up the hard USART (TX, RX, GND) pins and plug into my Linux serial port
2. Use printf's to try to find out what's happening.
3. Notice that the interrupt's vectors are not in the right spots and
interrupts are being used. Fix that but turn interrupts off to limit
possible problems.
4. The printf's tell me that it's getting pretty far in the code.

In MPLAB's case it does (the number is bdt_data.SetupPkt.bRequest):

USBCheckStdRequest 6 (GET_DSC)
USBCheckStdRequest 5 (SET_ADR)

In sdcc case it does

USBCheckStdRequest 6
USBCheckStdRequest 6

Not sure what this all means.

Also noticed that it's underflowing the stack and rebooting but this
might be from using printf which is known to be stack hungry. Try
printf_small and printf_tiny but neither work. Notice that when I use
printf in MPLAB the light stops flashing but the code still seems to
run as the Dev and Vendor ID's still show up.

It would be great to be able to find out where it's rebooting from
but I can't figure out how to do that.

I've got an ICD-2 but can I use that to debug the sdcc code? I
doesn't let me set breakpoints if I just load the HEX file.

I uploaded what I have to http://www.efn.org/~rick/pub/D_143.sdcc.2.tar.bz2

Thanks for the help.

Rick
rickbronson
 
Posts: 18
Joined: Thu Sep 20, 2007 3:18 pm

Postby polly » Thu Oct 11, 2007 10:10 am

Pure guessing here .. That looks kind of consistent with the PC not liking
the descriptor it receives and asking again for it. I seem to remember
when I tried SDCC-compiling the USB stack, a while back, kind of ignoring
those "rom pointer" macros in order to just get a compile, I later realised
their purpose in specifying that descriptor fields must be pulled from flash
address space rather than from data registers.
Any chance your printf's can verify the descriptors being sent are valid ?
<=>
polly
 
Posts: 190
Joined: Mon Jun 05, 2006 2:10 pm

Postby rickbronson » Thu Oct 11, 2007 6:21 pm

Polly,

When I printf the data in the loop below, it's not getting the right stuff.

Take a look at the asm below. I'm thinking the compiler has some
problem. Shouldn't 0023d4 be something like:

MOVF _pSrc


; .line 307; system/usb/usbctrltrf/usbctrltrf.c *pDst.bRam = *pSrc.bRom;
0023c8 c1f5 movff 0x1f5, 0 MOVFF _pDst, r0x00
0023ca f000
0023cc c1f6 movff 0x1f6, 0x1 MOVFF (_pDst + 1), r0x01
0023ce f001
0023d0 c1f7 movff 0x1f7, 0x2 MOVFF (_pDst + 2), r0x02
0023d2 f002
0023d4 0ef8 movlw 0xf8 MOVLW _pSrc
0023d6 6ef6 movwf 0xf6, 0 MOVWF TBLPTRL
0023d8 0ef9 movlw 0xf9 MOVLW (_pSrc + 1)
0023da 6ef7 movwf 0xf7, 0 MOVWF TBLPTRH
0023dc 0efa movlw 0xfa MOVLW (_pSrc + 2)
0023de 6ef8 movwf 0xf8, 0 MOVWF TBLPTRU
0023e0 0009 tblrd *+ TBLRD*+
0023e2 cff5 movff 0xff5, 0x3 MOVFF TABLAT, r0x03

When I change the code, it looks better:

rom unsigned char *pRom;
pRom = pSrc.bRom;

; .line 308; system/usb/usbctrltrf/usbctrltrf.c *pDst.bRam = *pRom;
00242a c1f6 movff 0x1f6, 0x3 MOVFF _pDst, r0x03
00242c f003
00242e c1f7 movff 0x1f7, 0x4 MOVFF (_pDst + 1), r0x04
002430 f004
002432 c1f8 movff 0x1f8, 0x5 MOVFF (_pDst + 2), r0x05
002434 f005
002436 c000 movff 0, 0xff6 MOVFF r0x00, TBLPTRL
002438 fff6
00243a c001 movff 0x1, 0xff7 MOVFF r0x01, TBLPTRH
00243c fff7
00243e c002 movff 0x2, 0xff8 MOVFF r0x02, TBLPTRU
002440 fff8
002442 0009 tblrd *+ TBLRD*+

Please try out http://www.efn.org/~rick/pub/D_143.bug.1.tar.bz2 and
tell me if you think this is a compiler problem. It's a striped
version that only has the suspect code.
Here is what it prints:

main bRam = 0x0 sb device_dsc = 0x11
main bRam = 0x0 sb device_dsc = 0x12
main bRam = 0x0 sb device_dsc = 0x0
main bRam = 0x0 sb device_dsc = 0x0
main bRam = 0x0 sb device_dsc = 0xffffffd8
main bRam = 0x0 sb device_dsc = 0xa
main bRam = 0x0 sb device_dsc = 0x0
main bRam = 0x0 sb device_dsc = 0x1
main bRam = 0x0 sb device_dsc = 0x2
main bRam = 0x0 sb device_dsc = 0x0

Thanks very much.

Rick
rickbronson
 
Posts: 18
Joined: Thu Sep 20, 2007 3:18 pm

Postby polly » Fri Oct 12, 2007 8:21 am

Hello Rick,
Yes, that looks to me as if the compiler isn't doing what we want; I just
don't know how it's expected to behave. I'll have to learn asm after all !

p
<=>
polly
 
Posts: 190
Joined: Mon Jun 05, 2006 2:10 pm

Next

Return to USB Development

Who is online

Users browsing this forum: No registered users and 2 guests

cron