CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Problem with USB Bootloader(ex_usb_bootloader)

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
javierpic



Joined: 28 Jun 2012
Posts: 6

View user's profile Send private message

Problem with USB Bootloader(ex_usb_bootloader)
PostPosted: Sat Jan 25, 2014 11:34 am     Reply with quote

Hi! I'm having a hard time trying to load a program using the usb bootloader that comes in the examples folder (ex_usb_bootloader).
I compile and load the bootloader with a programmer and then download the program using siow without problems but then the program loaded doesn't run! I checked fuses and I think the problem must be in usb_bootloader.h, I can't see where the problem is since I checked that is moving the program after the bootloader and reserving space for it. Please help!


This is the testing program I load from siow(flashing led)
Code:

#include <18F46J50.h>
#fuses INTRC_PLL_IO, PLL2,NOPROTECT,NODEBUG,NOCPUDIV,NODSBOR,NODSWDT,NOWPFP,NOWPCFG,NOWPDIS,NOFCMEN,NOIESO,RTCOSC_T1,WDT,WDT32768
#use delay(clock=48mhz)
#include <usb_bootloader.h>
#DEFINE LEDAMA PIN_B3

void main() {
 setup_oscillator(OSC_PLL_ON);
setup_adc (ADC_OFF);
setup_comparator (NC_NC_NC_NC);
SETUP_WDT (WDT_OFF);
port_b_pullups (FALSE);
output_LOW(LEDAMA);
DELAY_MS(100);
 
while(true){
 output_HIGH(LEDAMA);
 DELAY_MS(500);
 output_LOW(LEDAMA);
 DELAY_MS(500);
 }

}


This is the file usb_bootloader.h
Code:

#define LOADER_SIZE        (0x1FFF)
//#else
//#define LOADER_SIZE        (0x17FF)
//#endif

//the loader and application need a common flag that determines if we are in
//the bootloader or application, that way the ISR knows where to go.  this
//is the location in ram that is reserved for this flag.
#define LOC_IN_LOADER_FLAG  0x25

//// --- end configuration --- ////////////////////////////////////////////

#reserve LOC_IN_LOADER_FLAG

int8 g_InBootloader;
#locate g_InBootloader=LOC_IN_LOADER_FLAG

#define LOADER_START       (0)
#define LOADER_END         (LOADER_SIZE)
#define APPLICATION_START  (LOADER_SIZE+1)

#if defined(__USB_87J50__)
 #define APPLICATION_END    (getenv("PROGRAM_MEMORY")-9) //configuration bits
#else
 #define APPLICATION_END    (getenv("PROGRAM_MEMORY")-1)
#endif
#define APPLICATION_ISR    (APPLICATION_START+8)

#ifdef _bootloader
 /*
  Provide an empty application, so if you load this .HEX file into the pic
  without an application this will prevent the pic from executing unknown code.
 */
 #org APPLICATION_START,APPLICATION_START+0xF
 void BlankApplication(void)
 {
   while(TRUE);
 }

 //we need to prevent the loader from using application space
 #if (APPLICATION_END > 0x10000)
   #org APPLICATION_START+0x10, 0xFFFF {}
   #if (APPLICATION_END > 0x20000)
      #org 0x10000, 0x1FFFF {}
      #org 0x20000, APPLICATION_END {}
   #else
      #org 0x10000, APPLICATION_END {}
   #endif
 #else
   #org APPLICATION_START+0x10, APPLICATION_END {}
 #endif

  // #define  USB_CONFIG_PID       0x0034
   #define  USB_CONFIG_PID       0x0033
   #define USB_STRINGS_OVERWRITTEN
   
   
   char USB_STRING_DESC_OFFSET[]={0,4,12};

   // Here is where the "CCS" Manufacturer string and "SERIAL DEMO" are stored.
   // Strings are saved as unicode.
   // These strings are mostly only displayed during the add hardware wizard.
   // Once the operating system drivers have been installed it will usually display
   // the name from the drivers .INF.
 
  char const USB_STRING_DESC[]={
      //string 0
            4, //length of string index
            0x03, //USB_DESC_STRING_TYPE, //descriptor type 0x03 (STRING)
            0x09,0x04,   //Microsoft Defined for US-English
      //string 1  - manufacturer
            8, //length of string index
            0x03, //USB_DESC_STRING_TYPE, //descriptor type 0x03 (STRING)
            'C',0,
            'C',0,
            'S',0,
      //string 2 - product
            30, //length of string index
            0x03, //USB_DESC_STRING_TYPE, //descriptor type 0x03 (STRING)
            'C',0,
            'D',0,
            'C',0,
            ' ',0,
            'B',0,
            'o',0,
            'o',0,
            't',0,
            'l',0,
            'o',0,
            'a',0,
            'd',0,
            'e',0,
            'r',0
   };
#endif   //_bootloader


#ifndef _bootloader
 //in the application, this moves the reset and isr vector out of the bootload
 //space.  it then reserves the loader space from being used by the application.
 #build(reset=APPLICATION_START, interrupt=APPLICATION_ISR)
 #org 0, LOADER_END {}
#endif
Ttelmah



Joined: 11 Mar 2010
Posts: 19447

View user's profile Send private message

PostPosted: Sun Jan 26, 2014 2:00 am     Reply with quote

There is a big problem 'leaping out' here.

You can only use the internal RC oscillator, with PLL, for _low speed_ USB operation. (section 3.4 in the data sheet). The default USB configuration throughout, is 'fast' (high speed). CDC, can't be used with the CCS driver on a slow speed device (read the comments at the start of usb_cdc.h). This is fundamental, since standard CDC uses bulk transfers.
That you are not getting an error when you compile the bootloader, says this is set to use 'fast' (it will warn you that CDC can't work with the standard drivers and a slow speed device).
Remember the fuses used in the program _must_ match the fuses used in the bootloader. The fuses you post could only work with the USB configured for 'slow'.....
In a "can't work" loop here.

Best Wishes
javierpic



Joined: 28 Jun 2012
Posts: 6

View user's profile Send private message

PostPosted: Mon Jan 27, 2014 8:43 am     Reply with quote

Hi Ttelmah,
Thanks so much for your reply!. I checked in all the comments provided in the usb drivers provided and I couldn't find what you say, that CDC can't be used on a slow speed device(I pasted below the comments at the start of usb_cdc.h). What is the version of your compiler?(mine 4.114).
It would be very surprising if that is true because I've been using CDC with low speed for a very long time in different boards(I do it that way so I don't need to use a crystal) and never had any problems. Regarding the bootloader, isn't it suspicious that I'm able to create the serial comm and download the program with siow without problems?
Let me know what you think, I will start preparing a board with a crystal to be able to set the usb at full speed to try.
Thanks a lot!
Javier



Code:




/////////////////////////////////////////////////////////////////////////
////                                                                 ////
////                            usb_cdc.h                            ////
////                                                                 ////
//// Library for adding a virtual COM port on your PC over USB using ////
//// the standard Communication Device Class (CDC) specification.    ////
//// Including this file in your code will add all USB code,         ////
//// interrupts, descriptors and handlers required.  No other        ////
//// modifications need to be made.                                  ////
////                                                                 ////
//// This library creates a virtual RS232 link between the PC and    ////
//// the PIC, therefore the library provided will be familiar to     ////
//// anyone with standard UART stream I/O:                           ////
////                                                                 ////
//// usb_cdc_kbhit() - Returns TRUE if there is one or more          ////
////      character received and waiting in the receive buffer.      ////
////                                                                 ////
//// usb_cdc_getc() - Gets a character from the receive buffer.  If  ////
////      there is no data in the receive buffer it will wait until  ////
////      there is data in the receive buffer.  If you do not want   ////
////      to wait in an infinit loop, use usb_cdc_kbhit() first to   ////
////      check if there is data before calling usb_cdc_getc().      ////
////                                                                 ////
//// usb_cdc_putc(char c) - Puts a character into the transmit       ////
////      buffer.  If the transmit buffer is full it will wait until ////
////      the transmit buffer is not full before putting the char    ////
////      into the transmit buffer.  The transmit buffer is read by  ////
////      the PC very quickly, and therefore the buffer should only  ////
////      be full for a few milli-seconds.  If you are concerned     ////
////      and don't want to be stuck in a long or infinite loop,     ////
////      use usb_cdc_putready() to see if there is space in the     ////
////      transmit buffer before putting data into the transmit      ////
////      buffer.                                                    ////
////                                                                 ////
//// usb_cdc_puts(*ptr) - Sends the null terminated string to the    ////
////     the transmit buffer.  Unlike usb_cdc_putc() or              ////
////     usb_cdc_putc_fast(), this routine will fit the string in    ////
////     one packet (whereas the other functions will flush the      ////
////     buffer as soon as the endpoint is free).                    ////
////     Returns TRUE if the packet was sent, FALSE if the buffer    ////
////     was still in use.                                           ////
////     Will stop copying characters from ptr to the endpoint       ////
////     buffer once it is full (but it will still return TRUE).     ////
////                                                                 ////
//// usb_cdc_putready() - Returns TRUE if there is room left in the  ////
////      transmit buffer for another character.                     ////
////                                                                 ////
//// usb_cdc_connected() - Returns TRUE if we received a             ////
////      Set_Line_Coding.  On most serial terminal programs (such   ////
////      as Hyperterminal), they will send a Set_Line_Coding        ////
////      message when the program starts and it opens the virtual   ////
////      COM port.  This is a simple way to determine if the PC     ////
////      is ready to display data on a serial terminal program,     ////
////      but is not garaunteed to work all the time or on other     ////
////      terminal programs.                                         ////
////                                                                 ////
//// usb_cdc_putc_fast(char c) - Similar to usb_cdc_putc(), except   ////
////      if the transmit buffer is full it will skip the char.      ////
////                                                                 ////
//// usb_cdc_line_coding - A structure used for Set_Line_Coding and  ////
////       Get_Line_Coding.  Most of the time you can ignore this.   ////
////                                                                 ////
//// usb_cdc_break - If the PC has sent a break command, this will   ////
////       hold the break time (in milli-seconds).  If the PC sends  ////
////       a value of 0xFFFF the device is supposed to hold the      ////
////       break until it sends a value of 0                         ////
////                                                                 ////
//// usb_cdc_carrier - Where Set_Control_Line_State value is stored. ////
////       Of most relevance is the field dte_present, which is the  ////
////       DTR setting.                                              ////
////                                                                 ////
//// The following functions are also provided, and are ports of the ////
//// I/O functions in input.c.  See input.c and the CCS manual for   ////
//// documentation:                                                  ////
////   get_float_usb() - Read a float number from the user           ////
////   get_long_usb() - Read a long number from the user             ////
////   get_int_usb() - Read an integer number from the user          ////
////   get_string_usb(char *s, int max) - Read a string from the user. ////
////   gethex_usb() - Read a byte, in HEX, from the user             ////
////   gethex1_usb() - Read a HEX character                          ////
////                                                                 ////
//// This driver will load all the rest of the USB code, and a set   ////
//// of descriptors that will properly describe a CDC device for a   ////
//// virtual COM port (usb_desc_cdc.h)                               ////
////                                                                 ////
//// An .INF file is provided (cdc_NTXP.inf) that will load the      ////
//// standard CDC drivers for a virtual COM port in Windows          ////
//// NT/2000/XP and above.                                           ////
////                                                                 ////
/////////////////////////////////////////////////////////////////////////
////                                                                 ////
//// VERSION HISTORY                                                 ////
////                                                                 ////
//// Jan 28, 2010:                                                   ////
////  Added usb_cdc_puts(str), which will fit the entire str into    ////
////     one packet.                                                 ////
////                                                                 ////
//// Jan 25, 2010:                                                   ////
////  Ignore incoming 0 length packets.                              ////
////                                                                 ////
//// June 9th, 2009:                                                 ////
////  Some problems with Vista and fast hubs/hosts fixed on PIC18.   ////
////                                                                 ////
//// April 7th, 2009:                                                ////
////   Vista 'code 10' issues resolved.                              ////
////                                                                 ////
//// March 5th, 2009:                                                ////
////   Cleanup for Wizard.                                           ////
////   PIC24 Initial release.                                        ////
////                                                                 ////
//// Nov 26th, 2007:                                                 ////
////              usb_cdc_put_buffer_free() should be more stable.   ////
////              Fixed a hang-up that would happen if you sent      ////
////                 exactly 64 bytes.                               ////
////                                                                 ////
//// Nov 6th, 2007:                                                  ////
////              Compatabible with latest pic18_usb.h, which        ////
////                 reduces RAM footprint of USB driver.            ////
////              This driver now fits on 18F4450/2450 PICs.         ////
////                                                                 ////
//// October 27th, 2005: Changed the way incoming packets are        ////
////               handled in that CDC driver will not flush         ////
////               endpoint until user has handled all data.  This   ////
////               will prevent overflows as the USB will NAK        ////
////               incoming packets until it is ready to receive     ////
////               more.                                             ////
////            When using 18F4550 family, the RX buffer is          ////
////               mapped directly to the endpoint buffer - this     ////
////               saves a chunk of RAM.                             ////
////            When using the 18F4550 family, you can increase      ////
////               the TX and RX size over 64 bytes.                 ////
////            No longer send 0len packets in the TBE interrupt.    ////
////            Hopefully fixed bugs that caused random crashes      ////
////               if you tried sending more than 64 bytes.          ////
////                                                                 ////
//// July 6th, 2005: Global interrupts disabled when writing to TX   ////
////                   buffer.                                       ////
////                                                                 ////
//// July 1st, 2005: Initial Release.                                ////
////                                                                 ////
/////////////////////////////////////////////////////////////////////////
////        (C) Copyright 1996,2005 Custom Computer Services         ////
//// This source code may only be used by licensed users of the CCS  ////
//// C compiler.  This source code may only be distributed to other  ////
//// licensed users of the CCS C compiler.  No other use,            ////
//// reproduction or distribution is permitted without written       ////
//// permission.  Derivative programs created using this software    ////
//// in object code form are not restricted in any way.              ////
/////////////////////////////////////////////////////////////////////////

/*
   usb_cdc_putc() will not work correctly if interrupts are disabled, this
   also means it will not work if you call usb_cdc_putc() from inside another
   interrupt.
   
   Workaround is to call  _usb_cdc_putc_fast_noflush() instead.  This routine
   will erase last character if you put too many characters into the endpoint
   buffer.  Since this routine doesn't flush the endpoint buffer, you will
   also have to add this code in your main loop to check if buffer needs
   to be transmitted:
      if (usb_cdc_put_buffer_nextin && usb_cdc_put_buffer_free())
      {
         usb_cdc_flush_out_buffer();
Ttelmah



Joined: 11 Mar 2010
Posts: 19447

View user's profile Send private message

PostPosted: Tue Jan 28, 2014 9:22 am     Reply with quote

Look further down.

Search for the keyword 'USB_USE_FULL_SPEED' (which is the flag to say that the code is being compiled for a full speed or slow device).

Technically CDC, with 'slow' was supported on the original V1 USB spec, and dropped in 1.2. There are quite a few drivers around that use this in 'reverse compatibility' mode, but the standard Windows driver (which CCS uses), doesn't. That the compiler is not issuing the warning, says you are actually compiling in 'full speed' mode, which is not compatible with the fuses you are selecting (the RC oscillator with PLL doesn't support fast).

Best Wishes
javierpic



Joined: 28 Jun 2012
Posts: 6

View user's profile Send private message

PostPosted: Mon Feb 03, 2014 9:37 pm     Reply with quote

Hi Ttelmah,
I was able to finish another a board with a crystal. So I got the usb working at full speed, load the bootloader with the programmer, and load the program with siow. I get the same problem as before, it doesn't work...any other ideas?

Code:

#include <18F46J50.h>
#fuses HSPLL,PLL5,NOWDT,NOPROTECT,NODEBUG,NOCPUDIV,NODSBOR,NODSWDT,NOWPFP,NOWPCFG,NOWPDIS,NOFCMEN,NOIESO,RTCOSC_T1
#use delay(clock=48mhz)
#include <usb_bootloader.h>

#DEFINE LEDAMA PIN_B3



void main() {
 setup_oscillator(OSC_PLL_ON);
setup_adc (ADC_OFF);
setup_comparator (NC_NC_NC_NC);
SETUP_WDT (WDT_OFF);

port_b_pullups (FALSE);
output_LOW(LEDAMA);
DELAY_MS(100);
 
while(true){
 output_HIGH(LEDAMA);
 DELAY_MS(500);
 output_LOW(LEDAMA);
 DELAY_MS(500);}

}
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group