Hi all,
I have a design with the K70FN1M0VMJ15. The startup code is simple but everything works fine when starting via the JLINK probe. However the bard doesn't boot directly (without the probe and running with command). The reset pin pulses continously at interval.
I have stripped the startup to as simple as just disabling the internal watchdog and then flashing indicator but still the same - it won't boot on it's own.
Does anyone have any idea what might be the issue? (yes, reset is pulled up, EZ_CS also).
Vector table (in flash) starts at address 0
first it is supposed to runs small assembly code for startup and then calls start.
LED blinks as expected if run via the JLINK connection but nothing happes at reset or power up in hardware.
void
start(int state)
{
wdog_disable(); // disable the internal watchdog
....
void wdog_disable(void)
{
unsigned int icnt=0;
unsigned int iloop = 0;
/* First unlock the watchdog so that we can write to registers */
WDOG_UNLOCK = 0xC520;
WDOG_UNLOCK = 0xD928;
/* Clear the WDOGEN bit to disable the watchdog */
WDOG_STCTRLH &= ~WDOG_STCTRLH_WDOGEN_MASK;
if (PMC_REGSC & PMC_REGSC_ACKISO_MASK)
{
PMC_REGSC |= PMC_REGSC_ACKISO_MASK;
}
/***************************** TEST **************************/
SIM_SCGC5 |= (SIM_SCGC5_PORTA_MASK \
| SIM_SCGC5_PORTB_MASK \
| SIM_SCGC5_PORTC_MASK \
| SIM_SCGC5_PORTD_MASK \
| SIM_SCGC5_PORTE_MASK \
| SIM_SCGC5_PORTF_MASK )
// ACTIVITY LED
PORTE_PCR(24) = (0 | PORT_PCR_MUX(PORT_PIN_MUX_CONTROL_PIN_ALT1));
GPIOE_PDDR |= (0x01 << 24);
GPIOE_PCOR |= 0x01 << 24;
(GPIOE_PCOR |= 0x01 << 24);
do
{
} while (icnt++ <= 10000);
(GPIOE_PSOR |= 0x01 << 24);
do
{
if (icnt == 1)
(GPIOE_PSOR |= 0x01 << 24); // activity LED on
if (icnt == 64000)
(GPIOE_PCOR |= 0x01 << 24); // activity LED off
if (icnt >= 128000)
icnt = 0;
icnt++;
} while (1);
/***************************** TEST **************************/
}
Really hope that someone out there can give me some hint - been stumbling around this issue for quite a while.
Solved! Go to Solution.
Hello Kr. Kristinsson:
There are two explanations that come to my mind right now:
1) If using CodeWarrior, verify that you have not selected one of the semihosting libraries. Please check the next thread about this:
2) Similar issue was reported also in the thread of the next link. This was caused by the watchdog not being disabled early enough in the code, but the JLink connection seemed to disable the watchdog during debug session:
Re: Re: Can't boot TWR-K60N512 standalone...
If neither of these is your issue, please share your project to give it a check from my side.
Regards!,
Jorge Gonzalez
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hello Kr. Kristinsson:
There are two explanations that come to my mind right now:
1) If using CodeWarrior, verify that you have not selected one of the semihosting libraries. Please check the next thread about this:
2) Similar issue was reported also in the thread of the next link. This was caused by the watchdog not being disabled early enough in the code, but the JLink connection seemed to disable the watchdog during debug session:
Re: Re: Can't boot TWR-K60N512 standalone...
If neither of these is your issue, please share your project to give it a check from my side.
Regards!,
Jorge Gonzalez
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Jorge Gonzales
You are absolutely right, looking more closely to the startup assembly code it executed a stack fillup before it disabled the watchdog. Placing the disable watchdog process before it (first in startup) the problem was solved. Didn't notice this small call to stack fillup (seemed innocent enough to me at the time). This is very time critical indeed.
Thanks for your reply.
Best regards,
Mummi