• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 669 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

G2553 unknown reset cause?

Joseph Woodrell
Intellectual 920 points

Hey guys i was having trouble getting the usb code(BBUSB) to work on my new board, I had loaded the code that did work fine last time, but this time nothing. so i decided to go back to a known point for testing and proving out the board first.

 

the chip is a G2553

I loaded the base "BBUSB003" code OPossum posted here

However the chip just resets over and over, , how can I figure out what is triggering the reset to happen :smile:

This is what I've found so far

  • the watchdog is disabled
  • I am using a crystal, but spitting ACLK out p1.0 and it is a nice consistent 32.768 kHz so I know its not a crystal fault.
  • I'm doubtful there is an unaddressed interrupt because that bbusb003 code is known to work as posted. 
  • VCC is stable at 3.6v
  • the reset line is pulled high and isn't varying

I'm not sure what else to check for, or even how to write trap code for a chip reset cause when it resets,it dumps out of whatever code you have and just starts over.

  • 0
    Guru 46710 points

    Joseph Woodrell said:
    However the chip just resets over and over, , how can I figure out what is triggering the reset to happen :smile:

    By debugging. Or asking someone familiar with code you are referring to. Would be worth to try asking in the 43oh forum ?

  • 0 in reply to Ilmars
    Intellectual 920 points

    oddly, the compiler is complaining of port 1 not having an ISR, when it is clearly defined

    warning - "Interrupt vector "PORT1" does not have an interrupt handler routine."

    the ISR is defined in an ASM file along with the ISR itself

    "  
    .sect     ".int02"
    .word    USB_Sync

    "

    as best I can tell the compiler is either optimizing out the assembly file that the interrupt is called in or ignoring it completely  when I try to set breakpoints anywhere in the Assembly file  it kicks back

    "no code associated with "" line 586 in any loaded symbols"

    I tried setting "optimization off" in the project properties menu.    what can I do to force it to keep the stuff in the ASM file... it didn't have this issue with CCS 4 (which is what the code was originally written in)

  • 0 in reply to Joseph Woodrell
    Guru 227245 points

    Joseph Woodrell said:
    the compiler is either optimizing out the assembly file that the interrupt is called in or ignoring it completely

    The second one. Since the compiler doesn't care for assembly files. The compiler compiles C files, nothing else.

    Perhaps you forgot to add the ASM dile to the project. Just putting it into the project folder isn't enough. Eclipse needs to know that it shall run this file through the assembler and linker. Else the linker won't add the code to the binary, and the program will reset because the ISR is missing (as the error already told you).

    It's also possible that the assembly file is indeed ignored - because nothing in it is referenced anywhere.

    The linekr only keeps files whose content is externally referenced.
    The reset vector references the C startup code, the startup code references main, main references other functions etc.And each file wher eat least one objec tinit is referenced this way, is kept completely. This is why ISRs that are in the same file as a funcitont at is directly called (e.g. main, or a funciton that is alled by main) is included into th ebuild.
    However, your assembly file is NOT referenced from anywhere. While being a vital part of the code, it is completely self-contained (containing the ISR as well as the only reference to the ISR in .int02). So the linker will ignore it unless explicitely told to include it.

    If you don't find a way to force its inclusion, a way to trick the linker is to add a reference.

    extern void isr_name()(void)
    void (*ref)(void) = &isr_name;

    This generates a function pointer to the ISR. We never use it anywhere, but the compiler doesn't know and will generate a reference to the ISR. And the linker will therefore keep the ISR into the build.

**Attention** This is a public forum