Página 1 de 1

Estabilidade da CPU startup´s.s

MensagemEnviado: 14 Dez 2009 07:15
por 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

MensagemEnviado: 14 Dez 2009 07:18
por 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.

.

MensagemEnviado: 14 Dez 2009 07:26
por 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.

MensagemEnviado: 14 Dez 2009 07:32
por 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

MensagemEnviado: 14 Dez 2009 08:06
por 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

MensagemEnviado: 14 Dez 2009 08:11
por 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.

MensagemEnviado: 14 Dez 2009 08:12
por 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

MensagemEnviado: 14 Dez 2009 08:50
por proex
Djalma, esse delay só é usado durante o desenvolvimento, depois de definido o programa, tira-se esse delay.

MensagemEnviado: 14 Dez 2009 09:13
por 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;
}

MensagemEnviado: 14 Dez 2009 09:16
por 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.

MensagemEnviado: 14 Dez 2009 10:05
por 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

MensagemEnviado: 14 Dez 2009 13:19
por 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?

MensagemEnviado: 14 Dez 2009 16:15
por 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

MensagemEnviado: 14 Dez 2009 16:57
por 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.