Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-1964753 ] Weird oscillator problem with crt code
|
From: SourceForge.net <no...@so...> - 2008-05-20 17:26:38
|
Bugs item #1964753, was opened at 2008-05-15 18:12 Message generated for change (Comment added) made by seventhguardian You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1964753&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pic16 target Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: SeventhGuardian (seventhguardian) Assigned to: Nobody/Anonymous (nobody) Summary: Weird oscillator problem with crt code Initial Comment: I'm having an almost impossible problem, fully reproducible with two separate pic18f2685. The problem is experienced with this simple code: #include <pic18fregs.h> code char at __CONFIG1H conf1 = _OSC_IRCIO7_1H; code char at __CONFIG3H conf2 = _MCLRE_ON_3H & _PBADEN_OFF_3H; code char at __CONFIG2H conf3 = _WDT_OFF_2H; // DIsable WDT void main() { OSCCON = 0x70; while(1); } I'm selecting the internal oscillator with clock output on RC7. The "OSCCON" thing sets the internal oscillator to 8MHz operation. I'm monitoring the clock output IO pin with an oscilloscope. Compiling the file with (note the --no-crt): $ sdcc main.c -mpic16 -p18f2685 --optimize-cmp --optimize-df --no-crt ... the clock out is immediately set to 8MHz, and is kept there. On the other hand when compiling without the "--no-crt" option, the clock starts at 1MHz, then you can see it switching to 8MHz (proving that the main function is entered), but then it switches to about 833Hz !! (hertz, no typo!). I've looked at the generated assembly code, and apparently this is impossible to happen. I'm lost here.. I can provide the generated assembly code for both cases (with and without --no-crt). ---------------------------------------------------------------------- >Comment By: SeventhGuardian (seventhguardian) Date: 2008-05-20 17:26 Message: Logged In: YES user_id=1067152 Originator: YES I've managed to "workaround" this by using crt0.o, as I need to finish the project in a week. After that I should investigate further.. Strangely I'm facing really weird problems with this micro. Arrays don't work (you can write to them, but you read back garbage), and the same thing happens with local variables. With another code, sometimes the timer interrupts get called for a couple of seconds but then stop, and reseting the micro doesn't make it work again. I have to power cycle it (probably clearing some faulty registers) for it to work again for some seconds. Looking at the assembly output makes me believe that it _should_ work, so I'm really pulling my hair out here .. faulty hardware is becoming a strong possibility. ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2008-05-19 21:31 Message: Logged In: YES user_id=1115835 Originator: NO Sorry, this one is not resolved yet: a similar report on sdcc-user confused me. @SeventhGuardian: Any news? ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2008-05-19 08:49 Message: Logged In: YES user_id=1115835 Originator: NO Tracked down to a hardware problem off the list. ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2008-05-16 17:08 Message: Logged In: YES user_id=1115835 Originator: NO The sources for the CRTs reside in device/lib/pic16/startup/crt0*.c in the source package of SDCC. The difference between the two is that crt0i initializes the C-initialized global and/or static variables, whereas crt0 does not (crt0iz would additionally set all other memory locations to zero after reset and is the preferred one). All CRTs write to the (SFR) register 0xA6 to set up potential flash memory access; this *should not* harm non-flash devices... During initialization, the crt0i/crt0iz access program memory, evaluate a linker-defined structure there and copy the initializer values from program memory to RAM using TBLPTR, TABLAT, TBLRD*+, FSR0, and registers 0x00--0x09 in the access bank. No HW tests are performed. Sorry, but I cannot reproduce the problem. For the snippet above, crt0 would be fine, all others should work as well, though. --no-crt requires implementing an __interrupt 0-handler (RESET vector) in your code and is not recommended for common projects. Good luck, Raphael ---------------------------------------------------------------------- Comment By: SeventhGuardian (seventhguardian) Date: 2008-05-16 14:08 Message: Logged In: YES user_id=1067152 Originator: YES I've retested it today, and the problem reappeared. This time using crt0.o made it work, while using crt0i.o made the problem appear. I'm getting convinced that this may be a hardware problem mixed with a crt problem. Does crt0i.o do any hardware test that may explain this? ---------------------------------------------------------------------- Comment By: SeventhGuardian (seventhguardian) Date: 2008-05-15 19:05 Message: Logged In: YES user_id=1067152 Originator: YES Ok, now I am confused. I've went back to the start, but now I can't reproduce the problem. I'm not sure why, but I'll investigate. In the meantime I'll close the bug.. ---------------------------------------------------------------------- Comment By: SeventhGuardian (seventhguardian) Date: 2008-05-15 18:49 Message: Logged In: YES user_id=1067152 Originator: YES After a bit more digging I found out that the using --no-crt doesn't generate a proper reset vector: 00002a: ef17 goto 0x2e 00002c: f000 00002e: ec1b call 0x36, 0 000030: f000 000032: ef19 goto 0x32 000034: f000 000036: 0e70 movlw 0x70 000038: 6ed3 movwf 0xd3, 0 00003a: ef1d goto 0x3a 00003c: f000 00003e: 0012 return 0 So hopefuly the reset vector would work as a "nop", and the next instructions would be called. Strangely or not, when I add a delay function above the main function then the main doesn't get executed, and I end up with a 1MHz (default) clock. On the other hand, manually forcing the use of crt0 generates working code: $ sdcc main.c -mpic16 -p18f2685 --use-crt=/usr/share/sdcc/lib/pic16/crt0.o This makes me believe that the default crt is one of the "more complex" ones, and that the default crt is doing something nasty to the mcu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1964753&group_id=599 |