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 CCS Technical Support

[closed] 18F47J53 as usb-serial programmer not reliable :(
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
spilz



Joined: 30 Jan 2012
Posts: 220

View user's profile Send private message

PostPosted: Tue Nov 29, 2016 8:23 am     Reply with quote

I'm using V5.059
But the issue is still here when I don't use printf :(
By the way how to solve the issue with printf ?
Ttelmah



Joined: 11 Mar 2010
Posts: 20059

View user's profile Send private message

PostPosted: Tue Nov 29, 2016 8:41 am     Reply with quote

You show us a 'test' program, but not the rest of this (fuses, other code etc..).

Now what you show should work, but could easily be made 'not to work' by other things. For instance if there is an INT_RDA hander that does not correctly handle the received characters after a few mSec this can completely hang the chip. Or you could have the watchdog triggering (this would be the most likely cause for a failure after a time....).
spilz



Joined: 30 Jan 2012
Posts: 220

View user's profile Send private message

PostPosted: Tue Nov 29, 2016 8:52 am     Reply with quote

I'm not at home right now, I will post a full test program and verify if it works.

To close the parenthese about printf, how to solve it ?
Ttelmah



Joined: 11 Mar 2010
Posts: 20059

View user's profile Send private message

PostPosted: Tue Nov 29, 2016 9:04 am     Reply with quote

You've just proved you don't have an issue with printf, since you say it does the same with putc....
spilz



Joined: 30 Jan 2012
Posts: 220

View user's profile Send private message

PostPosted: Tue Nov 29, 2016 9:11 am     Reply with quote

But it always good to be aware when an issue is known.
temtronic



Joined: 01 Jul 2010
Posts: 9632
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Nov 29, 2016 9:13 am     Reply with quote

your 'program' couple of posts up show that global intrrupts are enabled yet there are no 'handlers'. That alone will 'freeze the PIC'...


Jay
Ttelmah



Joined: 11 Mar 2010
Posts: 20059

View user's profile Send private message

PostPosted: Tue Nov 29, 2016 11:10 am     Reply with quote

No it won't Temtronic.
The USB driver has a handler, and will enable the USB interrupt unless USB_ISR_POLLING is selected. It wouldn't work with this (since this requires USB_task to be called very frequently), but you must enable the global interrupt to make this all work.

Key question we still have not had answered is what compiler version?.

I'd honestly suspect the watchdog is enabled.
temtronic



Joined: 01 Jul 2010
Posts: 9632
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Nov 29, 2016 11:54 am     Reply with quote

I was thinking he might have some other interrupt that was crashing the 'program'.
While the USB diver handles the USN interrupt, what about 'something' earlier, not seen?
So far I've only seen code 'fragments', not the whole thing. He could have 'something' ahead of the 'program' he posted a few entries ago.
also having the WDT enable could be it...no 'fuses' shown in the program either...

Bottom line we aren't getting the whole, complete picture.....so it is hard to decide what exactly is causing the problem.

Jay
Ttelmah



Joined: 11 Mar 2010
Posts: 20059

View user's profile Send private message

PostPosted: Tue Nov 29, 2016 2:30 pm     Reply with quote

Agreed. I said this several posts ago...
spilz



Joined: 30 Jan 2012
Posts: 220

View user's profile Send private message

PostPosted: Tue Dec 06, 2016 8:06 am     Reply with quote

this is an exemple of code :
Code:
#include <18F47J53.h>
#device ADC=16

#fuses HSPLL,SOSC_HIGH,NOCLOCKOUT,NOFCMEN
#fuses WDT128,PLL1,PLLEN,STVREN,NODEBUG,NOCPUDIV
#use delay(clock=48 MHz,crystal=4 MHz,restart_wdt)

#define LED_G_pin                      pin_B2
#define LED_R_pin                      pin_D4 

#define LED_G(x)                       output_bit(LED_G_pin,x)
#define LED_R(x)                       output_bit(LED_R_pin,x)
   
#include <usb_cdc.h>

int32 TIMER0_Seconde = 0;
#INT_TIMER0
void  TIMER0_isr(void)
{
   set_timer0(18661);         // 1s overflow
   TIMER0_Seconde++;
}

char c =0;
void blink(){
   output_toggle(LED_R_PIN);
   if(usb_cdc_carrier.dte_present){
      usb_cdc_putc(c++);
   }
}


int sequence_B_state = -1;
int32 sequence_B_Seconde_last = 0;
void sequence_B(void){
   int32 delta = 0;
   
   if(TIMER0_Seconde<sequence_B_Seconde_last)
      sequence_B_Seconde_last = TIMER0_Seconde;
   
   delta = (TIMER0_Seconde-sequence_B_Seconde_last);
   
   if(delta >= 7){
      blink();
      sequence_B_Seconde_last = TIMER0_Seconde;
   }
}

void main() {
   setup_adc_ports(NO_ANALOGS|VSS_VDD);
   setup_timer_0(RTCC_INTERNAL|RTCC_DIV_256);      //1,4 s overflow
   setup_wdt(WDT_OFF);
   
   
   LED_R(0);
   LED_G(0);
   
   enable_interrupts(INT_TIMER0);
   usb_init_cs();
   usb_task();
   enable_interrupts(GLOBAL);     
       
   sequence_B_state = 1;
   
   while(true){
      restart_wdt();
      usb_task();
      enable_interrupts(GLOBAL);   
     
      sequence_B();
     
      LED_G(usb_cdc_carrier.dte_present);
     
   }
   reset_cpu();
}

The red led should toggle every 7secondes and send 1 byte, but with this code, led and sending become crasy.

So maybe an issue with timer
or an issue with memory (cf https://www.ccsinfo.com/forum/viewtopic.php?t=55734)

I'm using V5.064

any idea ?

thaks again for your help
Ttelmah



Joined: 11 Mar 2010
Posts: 20059

View user's profile Send private message

PostPosted: Tue Dec 06, 2016 8:53 am     Reply with quote

Without looking any further, one disastrous thing. You are not enabling the voltage regulator to feed the USB
Without this, you need to be feeding 3.3v into the VUSB pin.
I suspect this should be on.

#fuses VREGEN
spilz



Joined: 30 Jan 2012
Posts: 220

View user's profile Send private message

PostPosted: Tue Dec 06, 2016 8:55 am     Reply with quote

actually my VUSB is connected to 3.3v

should I add
Code:
#fuses VREGEN
?
Ttelmah



Joined: 11 Mar 2010
Posts: 20059

View user's profile Send private message

PostPosted: Tue Dec 06, 2016 9:23 am     Reply with quote

Sorry thought you were on one of the chips with the internal VREG.

How is the Vusb connected and smoothed?.

Your unreliability is typical for a problem with this level.

The same would apply on this chip with a problem on the Vcore smoothing. What capacitor have you got on this?. How close to the chip?.
spilz



Joined: 30 Jan 2012
Posts: 220

View user's profile Send private message

PostPosted: Tue Dec 06, 2016 9:27 am     Reply with quote

It's connected to 3.3v and has a 470nF to ground, as close as possible on pcb
Ttelmah



Joined: 11 Mar 2010
Posts: 20059

View user's profile Send private message

PostPosted: Tue Dec 06, 2016 9:48 am     Reply with quote

spilz wrote:
It's connected to 3.3v and has a 470nF to ground, as close as possible on pcb


What about Vcore?. They recommend a 10uF multilayer ceramic for this.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
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