Jump to content

Usb Problem 18f2450, 18f4450, 18f14k50


Recommended Posts

Hello

 

Ok I am having a very strange problem using the USB library from PICpack when used with any of the following 18F2450, 18F4450, 18F14K50.

 

http://embeddedadventures.blogspot.com/200...1-released.html

 

I am changing the addressing to match the USB RAM space. Here is the .map file that shows the USB descriptors in the correct memory space.

 

00000200:00000020			 gbl_bd0out					   bd0out
00000204:00000020			 gbl_bd0in						bd0in
00000208:00000020			 gbl_bd1out					   bd1out
0000020C:00000020			 gbl_bd1in						bd1in
00000210:00000020			 gbl_bd2out					   bd2out
00000214:00000020			 gbl_bd2in						bd2in
00000218:00000020			 gbl_bd3out					   bd3out
0000021C:00000020			 gbl_bd3in						bd3in
00000220:00000020			 gbl_bd4out					   bd4out
00000224:00000020			 gbl_bd4in						bd4in
00000228:00000020			 gbl_bd5out					   bd5out
0000022C:00000020			 gbl_bd5in						bd5in
00000230:00000020			 gbl_bd6out					   bd6out
00000234:00000020			 gbl_bd6in						bd6in
00000238:00000020			 gbl_bd7out					   bd7out
0000023C:00000020			 gbl_bd7in						bd7in
00000280:00000040			 gbl_buffer_0_out				 buffer_0_out
00000288:00000040			 gbl_buffer_0_in				  buffer_0_in
00000290:00000018			 gbl_buffer_1_in				  buffer_1_in

 

I am also able to replicate the problem with a 18F2455. Basically if the USB buffers are located at position 0x500 of memory then everything works fine. If I change the location to anything lower then 0x500 then the USB stops working and I simply get sent 0's as the USB descriptor.

 

Is there a problem with referencing locations below 0x500?

 

Has anyone got the BoostC compiler working with the USB peripherals on the 18F2450, 18F4450, 18F14K50 devices?

 

Microchip fixed this problem in their stack by removing the line stating that code started at location 0x500.

 

I am sure my settings are correct because I have done lots of work previously with USB and am now certain that all of my settings are correct. This leads me to beleive that the problem is with the compiler itself. I have also tried compiling with optimisation set to off but this resulted in the same problem.

 

Any help would be appreciated.

Link to post
Share on other sites
Should the discriptors not be in bank starting at 0x400.

 

Cheers

 

Reynard

 

 

Hi Reynard

 

The descriptors should be at 0x400 for the 18F2450 and the 18F4450 but the 18F14K50 has its USB RAM starting from location 0x200.

Link to post
Share on other sites
Ok I am having a very strange problem using the USB library from PICpack when used with any of the following 18F2450, 18F4450, 18F14K50.

 

...

 

I am sure my settings are correct because I have done lots of work previously with USB and am now certain that all of my settings are correct. This leads me to beleive that the problem is with the compiler itself. I have also tried compiling with optimisation set to off but this resulted in the same problem.

What aspect of the compiler do you think is wrong ??

 

Regards

Dave

Link to post
Share on other sites

I tried using USB and the PIC Pack 2.0 code on a PIC 18F2550 and only ever got gobledygook on the serial debug - I gave up in the end, meaning to come back to it when I had more time/patience.

 

I'm very interested to see a result here....

Link to post
Share on other sites

Hi Dave

 

What aspect of the compiler do you think is wrong ??

 

It seems that variable arrays under 0x500 have a problem.

 

The code is all dynamic so I assign a array of data with the address 0x500. This works fine. I then change the address to 0x480 for example and the code stops working and returns 0's. (obviously I can only do this on the devices with USB RAM above 0x500, devices without USB RAM over 0x500 do not work at all)

 

If you like I can wrap the code up into a sourceboost project and this way you might be able to spot the problem.

 

Mainly this topic is seeing if anyone has got the USB working with a 18F2450, 4450, 14K50 using BoostC?

 

 

I tried using USB and the PIC Pack 2.0 code on a PIC 18F2550 and only ever got gobledygook on the serial debug - I gave up in the end, meaning to come back to it when I had more time/patience.

 

I'm very interested to see a result here....

 

Hi Tim

 

The 18F2550 devices do not exhibit the problem as they have USB RAM memory above 0x500 hex. Seems your problem could be a incorrect configuration setting or crystal value.

Edited by Benj
Link to post
Share on other sites

Hello

 

Ok my code to assign the buffer addresses looks like this. As soon as I take an endpoint adress below 0x500 I get 0's returned.

 

#define USB_EP0_OUT_SIZE 	8
#define USB_EP0_OUT_ADDR 	0x0500
#define USB_EP0_IN_SIZE 	8
#define USB_EP0_IN_ADDR 	0x0508

#define USB_EP2_IN_SIZE		8
#define USB_EP2_IN_ADDR	0x0510

#define USB_EP3_OUT_SIZE	8
#define USB_EP3_OUT_ADDR	0x0518
#define USB_EP3_IN_SIZE		8
#define USB_EP3_IN_ADDR	0x0520

typedef struct _buffer_descriptor {
uns8			stat,
		count;
uns16	addr;
} buffer_descriptor;

buffer_descriptor bd0out@0x400;
buffer_descriptor bd0in @0x404;
buffer_descriptor bd1out@0x408;
buffer_descriptor bd1in @0x40C;
buffer_descriptor bd2out@0x410;
buffer_descriptor bd2in @0x414;
buffer_descriptor bd3out@0x418;
buffer_descriptor bd3in @0x41c;
buffer_descriptor bd4out@0x420;
buffer_descriptor bd4in @0x424;
buffer_descriptor bd5out@0x428;
buffer_descriptor bd5in @0x42C;
buffer_descriptor bd6out@0x430;
buffer_descriptor bd6in @0x434;
buffer_descriptor bd7out@0x438;
buffer_descriptor bd7in @0x43C;

uns8 buffer_0_out[USB_EP0_OUT_SIZE]@ USB_EP0_OUT_ADDR;
uns8 buffer_0_in [USB_EP0_IN_SIZE] @ USB_EP0_IN_ADDR;

#ifdef USB_EP1_IN_SIZE
uns8 buffer_1_in [USB_EP1_IN_SIZE] @USB_EP1_IN_ADDR;
#endif
#ifdef USB_EP1_OUT_SIZE
uns8 buffer_1_out [USB_EP1_OUT_SIZE] @ USB_EP1_OUT_ADDR;
#endif
#ifdef USB_EP2_IN_SIZE
uns8 buffer_2_in [USB_EP2_IN_SIZE] @ USB_EP2_IN_ADDR;
#endif
#ifdef USB_EP2_OUT_SIZE
uns8 buffer_2_out [USB_EP2_OUT_SIZE] @ USB_EP2_OUT_ADDR;
#endif
#ifdef USB_EP3_IN_SIZE
uns8 buffer_3_in [USB_EP3_IN_SIZE] @ USB_EP3_IN_ADDR;
#endif
#ifdef USB_EP3_OUT_SIZE
uns8 buffer_3_out [USB_EP3_OUT_SIZE] @ USB_EP3_OUT_ADDR;
#endif

 

The odd thing is that the buffer descriptors at 0x400 work ok its just the buffer arrays that seem to fail.

Link to post
Share on other sites

Hi Benj

 

Thanks. Looking at the spec sheet for the 2550 though, the USB memory starts at 400h for the Buffer descriptors.

 

As it happens, the PIC pack code uses endpoint out address at 500h anyway so I must have some other problem that needs ironing out. I used the code with only very few changes, so it should have worked.

 

Scratches head...

Link to post
Share on other sites

Hello Tim

 

You should be able to use these configuration settings to get your device up and running....

 

 

You can use the following crystal speeds: 4, 8, 12, 16, 20, 24, 40, 48MHz

 

Your configuration settings should then match these settings to get the USB to run correctly.

 

USB Clock Selection - clk src from 96MHz PLL/2

CPU Sys CLK Select - no divide

OCS Select - Match the value of your crystal

Oscillator - HS: HS+PLL, USB-HS

USB Voltage Regulator - Enabled

Watchdog timer - Disabled

 

Other options can be enabled or disabled at will. However be careful with the protect options and ensure that they are all set to disabled otherwise you can lock up your chip so it cannot be reprogrammed.

 

 

If you get it working try adjusting the buffer address to an address under 0x500. You will notice that this causes the program to fail for no apparent reason.

Link to post
Share on other sites

Hi Benj

 

FYI, the config settings for a 20Mhz crystal (PIC18F2550) were as follows when it was not working:

 

#pragma DATA _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC4_PLL6_1L & _USBDIV_2_1L

#pragma DATA _CONFIG1H, _FOSC_HSPLL_HS_1H & _FCMEN_OFF_1H & _IESO_OFF_1H

#pragma DATA _CONFIG2L, _PWRT_ON_2L & _BOR_OFF_2L & _VREGEN_ON_2L

#pragma DATA _CONFIG2H, _WDT_OFF_2H & _WDTPS_128_2H

#pragma DATA _CONFIG3H, _CCP2MX_OFF_3H & _LPT1OSC_OFF_3H & _PBADEN_OFF_3H & _MCLRE_OFF_3H

#pragma DATA _CONFIG4L, _STVREN_ON_4L & _LVP_OFF_4L & _DEBUG_OFF_4L & _XINST_OFF_4L

#pragma DATA _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L

#pragma DATA _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H

#pragma DATA _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L

#pragma DATA _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H

#pragma DATA _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L

#pragma DATA _CONFIG7H, _EBTRB_OFF_7H

 

 

I had this together on a breadboard & will try again a little later today...

 

regards

 

Tim

Link to post
Share on other sites

Hello Tim

 

I think that your problem is this line.

 

#pragma DATA _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC4_PLL6_1L & _USBDIV_2_1L

 

I think it should be like this.

 

#pragma DATA _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC1_PLL2_1L & _USBDIV_2_1L

 

But I can never really tell with these word things. Much better to assign a number in my opinion. Much less hit and miss.

 

This should work a lot better with your 20MHz crystal.

 

#pragma DATA 0x300000, 0x24
#pragma DATA 0x300001, 0xf
#pragma DATA 0x300002, 0x3f
#pragma DATA 0x300003, 0x1e
#pragma DATA 0x300004, 0x0
#pragma DATA 0x300005, 0x83
#pragma DATA 0x300006, 0x81
#pragma DATA 0x300007, 0x0
#pragma DATA 0x300008, 0xf
#pragma DATA 0x300009, 0xC0
#pragma DATA 0x30000a, 0xf
#pragma DATA 0x30000b, 0xE0
#pragma DATA 0x30000c, 0xf
#pragma DATA 0x30000d, 0x40

post-2888-1243501370_thumb.png

Edited by Benj
Link to post
Share on other sites

Hi Benj

 

It works!!!! Thanks for your help and suggestions.

 

I left the #pragmas as they were - the 16Mhz setting was what was in the original code, so I thought it best to keep it at it was.

 

The thing that made the difference was not debugging to the serial port. I suspect I had set the baud rate too low, as the Pickkit2 UART is not that fast, for the rest of the USB code to stay in time.

 

So I tried setting the USB_EPx_xxx_ADDR settings to 460 onwards. On connecting to the usb I got the message unknown USB device under USB controllers in device manager, which I could not connect to, though windows reports it as working properly! Changing the setting back makes the USB perform properly again.

 

I don't know it that helps?

Link to post
Share on other sites

Hello Tim

 

Thats great news glad you've got it working. Also glad you've managed to replicate my problem.

 

Anyone at Sourceboost up for giving this a go? Like I said the code all looks correct so it is my opinion that it is somehow the compiler that is at fault.

Link to post
Share on other sites

Can anyone see any reason why this wouldnt work correctly at 0x0480 when it does work at 0x0500?

 

 

#define USB_EP0_OUT_SIZE 8

#define USB_EP0_OUT_ADDR 0x0480

 

uns8 buffer_0_out[uSB_EP0_OUT_SIZE]@ USB_EP0_OUT_ADDR;

 

 

Im not going to give up on this. At least not yet :P

 

Ben

Embedded Engineer

Matrix Multimedia

Link to post
Share on other sites
Can anyone see any reason why this wouldnt work correctly at 0x0480 when it does work at 0x0500?

 

 

#define USB_EP0_OUT_SIZE 8

#define USB_EP0_OUT_ADDR 0x0480

 

uns8 buffer_0_out[uSB_EP0_OUT_SIZE]@ USB_EP0_OUT_ADDR;

 

 

Im not going to give up on this. At least not yet :P

 

Ben

Embedded Engineer

Matrix Multimedia

I do hope this problem gets resolved!

I would like to use 18f2450 for a usb application ,but until this issue is resolved I will have to wait.

Does anyone who works for sourceboost give support for people who use there products?

It seems a waste to buy a competitor's product, when sourceboost works for all of my applications except one!

Link to post
Share on other sites

Hi All,

Can anyone see any reason why this wouldnt work correctly at 0x0480 when it does work at 0x0500?

 

 

#define USB_EP0_OUT_SIZE 8

#define USB_EP0_OUT_ADDR 0x0480

 

uns8 buffer_0_out[uSB_EP0_OUT_SIZE]@ USB_EP0_OUT_ADDR;

 

 

Im not going to give up on this. At least not yet :P

 

Ben

Embedded Engineer

Matrix Multimedia

It goes like this; at SourceBoost Technologies we don't have this target device to see the problem and we don't have a great deal of USB experience either.

 

We will help where we can. Normally we help when someone provides code examples that do not work because the compiler has generated erroneous code

 

Regards

Dave

Link to post
Share on other sites

Hi Dave

 

Thanks for the reply.

 

Im sure you can see that adding USB support is great for both your compiler and for your customers. Also theres really not that much to the USB software driver, Its just Microchips USB stack that can be a bit of a mental challange. :P

 

I can provide you with one of our ECIO 18F4455 devices and a Flowcode implementation of the USB software if you require. :P

 

This seems to be able to replicate the problem quite well as memory space is available at 0x400 and 0x500.

 

If you PM me with your address then I will arrange to send the hardware and software out to you.

Link to post
Share on other sites
Can anyone see any reason why this wouldnt work correctly at 0x0480 when it does work at 0x0500?

 

 

#define USB_EP0_OUT_SIZE 8

#define USB_EP0_OUT_ADDR 0x0480

 

uns8 buffer_0_out[uSB_EP0_OUT_SIZE]@ USB_EP0_OUT_ADDR;

Ben,

 

Do you have the .casm file(s) of a working example and of a failing one? Looking at the differences might shed some light on this.

 

Best regards,

 

Jac

Link to post
Share on other sites
Hello

 

Ok my code to assign the buffer addresses looks like this. As soon as I take an endpoint adress below 0x500 I get 0's returned.

 

<snip>

 

The odd thing is that the buffer descriptors at 0x400 work ok its just the buffer arrays that seem to fail.

Ben,

 

I modified the usb_joy_mouse sample found in the picpack distribution and no surprise, it did not work. However, 5 hours debugging later...

 

Take a look at the function usb_handle_reset() in pic_usb.c. You'll find two hard coded references for the bd0out.addr and bd0in.addr. (0x0500 and 0x0508 respectively) Once I changed those to USB_EP0_OUT_ADDR and USB_EP0_IN_ADDR the code started working.

 

Best regards,

 

Jac

Link to post
Share on other sites

Jac your a star,

 

Many thanks for looking into this.

 

Dave, sorry for blaming the compiler I was sure I had been through and taken our all the hardcoded addresses. :unsure: Obviously I missed these ones hidden away inside a function. You should receive an ECIO in a couple of days so hopefully this will help you to forgive me. Also it will work fine with the PICpack or Flowcode so feel free to have a play.

 

Thanks for everyones responces and help to get this problem under control. USB is now finally available for all USB PIC targets using BoostC :lol:

Link to post
Share on other sites

Hello Tim

 

ECIOs are essentially a USB enabled microcontroller device complete with USB bootloader and capable of supplying power to other devices from the USB power.

Edited by Benj
Link to post
Share on other sites

Benj,

Dave, sorry for blaming the compiler I was sure I had been through and taken our all the hardcoded addresses. :unsure: Obviously I missed these ones hidden away inside a function. You should receive an ECIO in a couple of days so hopefully this will help you to forgive me. Also it will work fine with the PICpack or Flowcode so feel free to have a play.
Glad this issue is resolved and that it turned out not to be a compiler problem :-)

I have received the ECIO modules, and have added them to my stock as I don't now need them for test. If I had know what you where going to send exactly I could have used one out of my stock - never mind.

 

Regards

Dave

Link to post
Share on other sites
  • 9 months later...
Jac your a star,

 

Many thanks for looking into this.

 

Dave, sorry for blaming the compiler I was sure I had been through and taken our all the hardcoded addresses. :unsure: Obviously I missed these ones hidden away inside a function. You should receive an ECIO in a couple of days so hopefully this will help you to forgive me. Also it will work fine with the PICpack or Flowcode so feel free to have a play.

 

Thanks for everyones responces and help to get this problem under control. USB is now finally available for all USB PIC targets using BoostC :lol:

 

Does any one have a working example of USB using the PICpack on the 18F14K50 chip,

From the other messages in this thread I think people already have it working and an example would be superb.

Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...