UBW boot-block broken?  [SOLVED]

USB PICs and the UBW

Moderator: phalanx

UBW boot-block broken?

Postby lucky luke » Mon Apr 09, 2012 2:53 am

Hi again,

After solving the vista - UBW communication problem, I continued with some testing.
I did write a simple ADC program, connected a 10K potentiometer to B0 (an12) to see if I could figure out the adc working.
Here is my code:
Code: Select all
/*********************************************************************
 * Hello World - just turn an LED on UBW by potentiometer on RB0
 ********************************************************************/
#include <p18cxxx.h>
#include <adc.h>
#include <delays.h>

#pragma config WDT = OFF

#define LED_1              LATCbits.LATC0
#define LED_2              LATCbits.LATC1

void main(void)
{
   int result=0;
   
   TRISBbits.TRISB0=1;            // analog input, channel 12
   TRISCbits.TRISC0=0;            // normal LED S1 on UBW
   
   OpenADC(ADC_FOSC_2 & ADC_RIGHT_JUST & ADC_12_TAD,
         ADC_CH12 & ADC_INT_OFF & ADC_REF_VDD_VSS,
         ADC_6ANA);   // Open the ADC in the Channel 12 (RB0, AN12) with +5V reference level (=Vdd) and 0V as Vss.
   while(1)      
   {
      Delay10TCYx( 5 );
      ConvertADC();
      while(BusyADC());
      result=ReadADC();
      if(result>=205) LED_1=1;   // LED is ON if Voltage supplied is greater than 1Volt.
      if(result<204) LED_1=0;      // LED is OFF otherwise.
      Delay10KTCYx(250);          // Wait for a moment, just to relax all
   }
   CloseADC();   // In reality, the ADC is never closed due to the while(1)...
}


This compiles without problems so far, I continued to program the hex file.
When I selected the hex file, a message did appear: 'Configuration data contained in this hex file is different from boards default setting. Using a different setting could cause the bootload interface to stop functioning. Yes/no/cancel'

I thought that the boot settings were protected and that this would possibly destroy the demo mode interface. I continued.
The programming was no problem, (the program however did not function as planned, the LED turns on at 0.25 volt) but now my computer is not recognizing the UWB anymore. The leds are not blinking, the S2 (red) is continuously on. The pc gives the balloon message: unrecognized usb-device. In more information it tells me to reconnect the device and when that is not solving the problem, replace the device.

What I hope you guys (and girls?) can tell me: Do I need to reprogram the complete UBW (finding a programmer device somewhere etc) and more important: how to avoid this? While my program functions properly.

thanks already, Luke
lucky luke
 
Posts: 5
Joined: Sat Apr 07, 2012 11:57 am

Re: UBW boot-block broken?

Postby EmbeddedMan » Mon Apr 09, 2012 6:48 am

Luke,

Yes, you will likely need to get a PICKit2 or PICKit3 (or some other ICSP programmer) and re-program the bootloader onto your UBW.

It is possible, using the Microchip PS software, to re-program the config bits. This is a 'feature' so that people who need to change some config bits for their application (like turning the watchdog on or off, or configuring certain peripherals) can flip those bits so their application works. The downside is that it's not too hard to accidentally include config bits into your application that conflict with the proper functioning of USB, and thus brick your board.

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

Re: UBW boot-block broken?

Postby lucky luke » Mon Apr 09, 2012 10:22 am

Thank you Brian!
I will search for a other programmer. I do 'somewhere' have one, hoping this oldie is able to program this chip.

However, I hope that I can write my program's without having continuous problems with the UBW, otherwise I could have bought a pickit instead of a UBW. What restrictions do I have when programming? I suppose this time it was the WDT that caused the problem, but I hope to avoid it off course.

Edit: Dear Brian, I tried to hardwire the PIC and loaded the hex file of 1.49 (and later on the 1.47 which I think I had) but got a message that the hex did not contain the fuses information. Therefore, now my embedded program is removed and the boot-mode is still not working? Can you explain me how to reconfigure the fuses-bits?
I will first try to erase the PIC completely, hoping that it will reset the fuses. This did not work. Not my computer is not even noticing it when I connect or reset the device, it only supplies it's power.
lucky luke
 
Posts: 5
Joined: Sat Apr 07, 2012 11:57 am

Re: UBW boot-block broken?

Postby EmbeddedMan » Wed Apr 11, 2012 11:12 am

If you have a blank PIC (or a non-blank one for that matter) and you want to program the UBW Bootloader (which contains the config bits), simply use the bootloader HEX file from the UBW website (http://schmalzhaus.com/UBW/FW/B/output_24MHz/FW_B_24MHz.hex for 24MHz crystals) and your ICSP programmer. Erase the chip first, then program on the bootloader HEX file. All of the config bits will then be programmed.

Then, when you want to write some code for the UBW, make sure that you do not allow any config bits into your firmware's HEX file. For example, the Hello World demo project does not include any config bits in its HEX file. Then use the bootloader to program that firmware HEX file, and the bootloader won't touch the existing config bit settings.

If, at some point, you want to over-ride some of the existing config bit settings (from the bootloader project) in your firmware, simply copy the config bit settings from the bootloader project into your project, and modify the ones you feel you need to change. Then your firmware WILL have config bits in the HEX file, and the bootloader app will ask you if you really want to change them when you use the bootloader to program your new firmware HEX file, and you'll tell it to calm down and allow the change.

Make sense?

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

Re: UBW boot-block broken?  [SOLVED]

Postby lucky luke » Thu Apr 12, 2012 11:02 am

Thanks Brian!

Sure, it makes sense. However, in my opinion it would be safer to better secure the bootloaderblock by the FS program. Having to change a menu/setting to be able of changing the fuses.
The firmware supplied here did not contain the fuses information, at least, that is what my program did message. Thanks, now I can continue experimenting and programming!
lucky luke
 
Posts: 5
Joined: Sat Apr 07, 2012 11:57 am


Return to USB Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron