Página 1 de 1
Estabilidade da CPU startup´s.s
Enviado:
14 Dez 2009 07:15por fabim
Pessoal, estava sofrendo bagarai com um bug que não encontrava de forma alguma.
Algumas vezes ao inicializar o arm, conforme constatei, ele engolia caroço na setagem dos pinos para o lcd, e algumas outras coisas.
Desconfiei da mão, e fiz a setagem do PLL manualmente conforme APP´s da nxp, e o problema se manteve.
Lembrei, ou acho que tinha lembrado, que o proex havia me dito que é bom logo apos o main colocar um delay longo, de segundo pra cima...
Fiz dois delays de 900mS em laço, um após o outro e os problemas acabaram.
Se o startup´s ja tem a rotininha que espera o pll estabilizar, e mesmo fazendo na unha é o mesmo procedimento.
Porque depois de colocar os delays, os problemas acabaram ?
Abraços
Fabim
Enviado:
14 Dez 2009 07:18por proex
Esse delay na primeira linha do Main é pra dar tempo para a interface Jtag tomar conta do chip.
Se não tiver esse delay muitas vezes o jtag nao consegue parar o chip pra inicializar o debuger.
Talves esse delay esteja ajudando pois dá tempo para o reset do display atuar.
Veja no datasheet do display, qual o tempo que ele precisa para o reset interno, antes desse temppo terminar nao adianta mandar comandos pra ele.
.
Enviado:
14 Dez 2009 07:26por Rodrigo_P_A
proex escreveu:Esse delay na primeira linha do Main é pra dar tempo para a interface Jtag tomar conta do chip.
Se não tiver esse delay muitas vezes o jtag nao consegue parar o chip pra inicializar o debuger.
.
isso mesmo, pq vamos supor que no seu programa você alterou alguma configuração de I/O que bloqueou os pinos do JTAG? se você tiver este delay antes de chamar as suas inicializações de HW, mesmo após um reset sua JTAG conseguirá se comunicar com o ARM.
Este problema é pior ainda em chips Cortex da Luminary, qdo eu comecei a mexer com eles eu não tinha pensado que este problema poderia acontecer e como eu fiz um programa errado eu gravei no ARM da Luminary e depois eu não conseguia mais acessar o CHIP via JTAG e o pior é que o chip da luminary não tem como gravar usando serial, ou seja, eu perdi o chip, tive que tirar ele da placa e colocar outro.
Enviado:
14 Dez 2009 07:32por fabim
nossa, achei que só micoxipe tinha a mainha<<<.
alguns NXPITOS tambem tem..
mais isso é pra 21XX ?
Tipo o LPC2368 tem a interface Jtag dedicada, e não compartilhada com mais nadegas.
Ou mesmo assim, a cpu deve desabilitar alguma coisa?
Abraços
Enviado:
14 Dez 2009 08:06por Rodrigo_P_A
fabim escreveu:nossa, achei que só micoxipe tinha a mainha<<<.
alguns NXPITOS tambem tem..
mais isso é pra 21XX ?
Tipo o LPC2368 tem a interface Jtag dedicada, e não compartilhada com mais nadegas.
Ou mesmo assim, a cpu deve desabilitar alguma coisa?
Abraços
A JTAG do 2368 tem I/O sim, é possível desabilitar a JTAG e usar os pinos como I/O.
vamos supor que você errou na configuração dos I/Os em seu soft e já entrou num pau no seu programa e esse seu programa desativou a JTAG. vc num vai mais conseguir acessar o CHIP pois ele vai rodar e já desabilitar a JTAG, vc só vai conseguir apagando via ISP, agora se tiver aquele delay antes das suas inicializações, vc vai conseguir executar o programa com a jtag e identificar o problema.
Microchip é muito bom eu acho, mas as eu tenho um pouco de trauma das ferramentas , principalmente dos compiladores C para PIC.
Re: Estabilidade da CPU startup´s.s
Enviado:
14 Dez 2009 08:11por Rodrigo_P_A
fabim escreveu:Pessoal, estava sofrendo bagarai com um bug que não encontrava de forma alguma.
Algumas vezes ao inicializar o arm, conforme constatei, ele engolia caroço na setagem dos pinos para o lcd, e algumas outras coisas.
Desconfiei da mão, e fiz a setagem do PLL manualmente conforme APP´s da nxp, e o problema se manteve.
Lembrei, ou acho que tinha lembrado, que o proex havia me dito que é bom logo apos o main colocar um delay longo, de segundo pra cima...
Fiz dois delays de 900mS em laço, um após o outro e os problemas acabaram.
Se o startup´s ja tem a rotininha que espera o pll estabilizar, e mesmo fazendo na unha é o mesmo procedimento.
Porque depois de colocar os delays, os problemas acabaram ?
Abraços
Fabim
sobre essa tal estabilização do PLL e esse delay, acredito que o problema seja outro, pois eu num peguei esse problema de PLL ainda.
Enviado:
14 Dez 2009 08:12por Djalma Toledo Rodrigues
Deixa ver
Hum segundo para o µC é uma "eternidade"
Provavélmente o probrema deve estar no Oscilador, não no PLL em si,
mas, no tempo para o oscilador atingir a amplitude necessária.
Sugiro fazer o seguinte só para confirmar:
Remova o xtal do µC
Remova esses delays no Soft.
Injete o sinal de um Oscilador externo, com a Amplitude adequada, antes de ligar o NPX
Depois post o resultado
DJ
Enviado:
14 Dez 2009 08:50por proex
Djalma, esse delay só é usado durante o desenvolvimento, depois de definido o programa, tira-se esse delay.
Enviado:
14 Dez 2009 09:13por tcpipchip
- Código: Selecionar todos
void SystemInit(void)
{
// --- enable and connect the PLL (Phase Locked Loop) ---
// a. set multiplier and divider
SCB_PLLCFG = MSEL | (1<<PSEL1) | (0<<PSEL0);
// b. enable PLL
SCB_PLLCON = (1<<PLLE);
// c. feed sequence
SCB_PLLFEED = PLL_FEED1;
SCB_PLLFEED = PLL_FEED2;
// d. wait for PLL lock (PLOCK bit is set if locked)
[b]while (!(SCB_PLLSTAT & (1<<PLOCK)));[/b]
// e. connect (and enable) PLL
SCB_PLLCON = (1<<PLLE) | (1<<PLLC);
// f. feed sequence
SCB_PLLFEED = PLL_FEED1;
SCB_PLLFEED = PLL_FEED2;
// --- setup and enable the MAM (Memory Accelerator Module) ---
// a. start change by turning of the MAM (redundant)
MAM_MAMCR = 0;
SCB_EXTPOLAR= 0x04;
SCB_EXTINT = 0x04;
// b. set MAM-Fetch cycle to 3 cclk as recommended for >40MHz
MAM_MAMTIM = MAM_FETCH;
// c. enable MAM
MAM_MAMCR = MAM_MODE;
// --- set VPB speed ---
SCB_VPBDIV = VPBDIV_VAL;
// --- map INT-vector ---
SCB_MEMMAP = MEMMAP_USER_FLASH_MODE;
}
Enviado:
14 Dez 2009 09:16por Rodrigo_P_A
proex escreveu:Djalma, esse delay só é usado durante o desenvolvimento, depois de definido o programa, tira-se esse delay.
eu costumo deixar, um delay, não de 1 segundo, mas de uns 300ms pelo menos, para que se eu precisar acessar o chip via JTAG eu conseguir.
Essa técnica eu uso também nos micros Coldfire pois se você mudar os pinos usados pelo BDM para I/Os depois você não vai conseguir mais utilizar o chip, nem regravá-lo.
Enviado:
14 Dez 2009 10:05por Djalma Toledo Rodrigues
proex escreveu:Djalma, esse delay só é usado durante o desenvolvimento, depois de definido o programa, tira-se esse delay.
Entendido Proex
mas, de qualquer forma, qual a causa, porque isso acontece ?
DJ
Enviado:
14 Dez 2009 13:19por proex
Djalma Toledo Rodrigues escreveu:proex escreveu:Djalma, esse delay só é usado durante o desenvolvimento, depois de definido o programa, tira-se esse delay.
Entendido Proex
mas, de qualquer forma, qual a causa, porque isso acontece ?
DJ
Isso o que?
Enviado:
14 Dez 2009 16:15por Djalma Toledo Rodrigues
Isso que o Fabim reportou:
" Algumas vezes ao inicializar o arm, conforme constatei, ele engolia caroço na setagem dos pinos para o lcd, e algumas outras coisas. "
DJ
Enviado:
14 Dez 2009 16:57por proex
Com certeza é algum bug no programa dele. Ele não deve estar respeitando alguma temporizaçao do display.
Essas coisas só acontecem com ele.