Por que.....por que.......por que ?

[proex]

Por que o programa funciona no modo Debuger mas não funciona rodando sozinho?

.

[tcpipchip]

O que o pessoal da KEIL diz ?

Reportou para eles ?

[proex]

Eles nem respondem a esse tipo de pergunta.

.

[xultz]

Uma vez eu fiz um firmware que ficava mandado bytes de status pela serial, para eu ficar monitorando enquanto ele rodava.
Quando terminei o fimrware e tava funcionando redondo, retirei o envio desses bytes e o firmware não funcionava mais.
Como meu prazo estava estourando, coloquei a transmissão de volta e deixei assim. O problema era de temporização, em alguns casos o atraso para enviar um byte ajudava a atrasar uma rotina que precisava de delay, mas eu nunca tive tempo de arrumar isso.

[Francesco]

Concordo com o Xults, tive esse problema com o NIOS. Normalmente cooca-se um delay e tudo volta a funcionar. Mas essa não é a melhor solução, é bom ver o que está realmente causando o travamento...

No nosso caso, alteramos algumas variáveis para "volatile" e tudo funcionou corretamente.

[pbernardi]

"funciona" é meio genérico.

O que acontece, dá uma exception, a placa cai, seu SO (se existe) fica maluco? Ou um determinado procedimento não funciona?

[proex]

É o seguinte, tenho uma placa Mestre com LPC2368 se comunicando com um Escravo via 485. Para cada comando enviado pelo Mestre, o Escravo devolve uma resposta.

Acontece que no modo Debuger, o Mestre reconhece a resposta enviada pelo Escravo, mas se deixar rodar Stand Alone, o Mestre nao reconhece a resposta enviada pelo Escravo.

A rotina de recepçao do Mestre fica aguardando uma resposta que ja chegou mas não foi detectada.

Entro no modo Debuger novamente, disparo o RUN e tudo funciona.

Eheheh, tá doido. Vou falar pro cliente vender a placa com o Jtag espetado nela.

[xultz]

Isso me lembra quando consertava rádio de avião, às vezes o rádio não pegava nada. Daí era só ligar o scope em qualquer coisa do rádio e ele pegava tudo, com um nível de recepção impressionante. Também dava vontade de devolver o rádio com um scope ligado nele.

[Francesco]

É o seguinte... caí numa sinuação parecida. No debug funcionava e no release não. A comunicação era serial.

Ele dava pau porque a flag de mensagem recebida era verificada e estava em 1. No entanto, por algum motivo bizonho ele na verdade não estava com tempo suficiente para abaixar a flag e esperar que ela subisse novamene.

No debug não deva problema porque era lento o suficiente para abaixar a flag antes de verificar. E com delay não dava problema porque dava um atraso antes de verificar a flag.

Mas a melhor solução foi a seguinte:

Código: Selecionar todos

// Espera ela abaixar.
while( flag == 1 )
     ;

// Espera ela levantar
while( flag == 0 )
     ;


Lógico que, uma vez validando isso, colocamos um timeout.

[MarcusPonce]

Realmente a situação típica de faltar um delay em algum lugar.

Não ficou claro se quem precisa estar em debug é o mestre ou o escravo, mas em RS485 tem um problema clássico que é o momento em que devemos chavear o sentido da RS485.
Acontece que se mudamos de tx para RX no instante que o hardware avisa que pode colocar mais um byte para transmitir dá problema, pois o último bit ou stop bit ainda não foi para a RS485...

[Renato]

E se a comunicação for half-duplex, ainda temos o tempo necessário
para o cancelamento de eco, ou seja, após uma Tx, o Rx fica fechado,
aguardando um tempo para não receber o eco do que ele próprio havia
transmitido.
O Tx remoto também deve aguardar após ativar o transmissor.
(Nos modems isso era feito pelo tempo RTS-CTS).

[polesapart]

Saca só:

Código: Selecionar todos

#define UART_LSR_THRE      0x20         // Transmiter Holding Register Empty
#define UART_LSR_TSRE      0x40         // Transmiter Shift Register Empty

Destes dois, o primeiro registrador é o que indica quando não há espaço na FIFO de transmissão, e o segundo indica quando finalizou de transmitir todos os bauds.


No codigo de transmissao rs-485, eu tenho aqui:

Código: Selecionar todos

/* comuta transceiver 485 para modo TX */
GPIO_IOSET = TX_EN;
delay_us(1); /* Aguarda 1 µs para estabilização do barramento. Na verdade este tempo é maior que o necessário, mas no projeto as bases de tempo mínimas são expressas em micro-segundos. O que ocorre é que quando ponho o transceiver em tx e já imediatamente solto um byte na FIFO de transmissão, as vezes o transceiver não consegue enviar o primeiro baud. No datasheet dos transceivers costuma ter um "transmit settle time" ou algo, assumindo que a parte elétrica do barramento esteja dentro dos padrões, é este intervalo mínimo que é preciso respeitar, descontado o tempo mínimo que o µC leva pra fazer o write no registrador da UART e o tempo que esta leva pra começar a pulsar os bauds, no caso dos LPC com ARM7 devem ser pelo menos 2 pulsos de clock. */


Depois é feita a transmissão de todos os caracteres, respeitando o estado da FIFO (por exemplo, consultando UART_LSR_THRE acima).

Ao finalizar o envio de todos os dados, aguarda-se a transmissão do último baud, e coloca-se o transceiver em modo RX:

Código: Selecionar todos

while (!(UART0_LSR & UART_LSR_TSRE));
GPIO_IOCLR = TX_EN;

Pode ser outra coisa mais cabeluda também, certeza que o código tá rodando bem fora do debug, tirando este problema? Ah, e boa sorte... hehehe.

[polesapart]

E se a comunicação for half-duplex, ainda temos o tempo necessário
para o cancelamento de eco, ou seja, após uma Tx, o Rx fica fechado,
aguardando um tempo para não receber o eco do que ele próprio havia
transmitido.
O Tx remoto também deve aguardar após ativar o transmissor.
(Nos modems isso era feito pelo tempo RTS-CTS).

Quando o 485 tá dentro dos parâmetros elétricos recomendados (fiação adequada, resistores de terminação corretos, mesmo transceiver ou pelo menos com a mesma especificação, etc) e lógicos (tempos de transmissão dentro dos adequados para o tranceiver e comprimento da fiação empregados), o eco (e não é só um pulso, é uma sequencia de reverberações) cai para valores aceitáveis em tempo inferior a um baud.

Mas claro que tem muito nego por aí rodando barramento 485 fora dos padrões, este que vos escreve inclusive ehehhehehe, apesar disso, em aplicações onde o "rx enable" e o "tx enable" do transceiver estão ligados em forma complementar (pinos unidos), não tenho observado pulsos no rx que tenham sido dependentes do último TX.

[Renato]

É verdade camarada ...
O tipo de linha de transmissão também influi.
Usa-se muito linha telefônica (Z=600 ohm) com resistor de terminação
120 Ohm ...
Mas tudo seria muito mais complicado numa speed rate de 256 kbps ...
Nos 9600 bps da vida é tudo soft ...
Mas no caso do camarada aí, é justamente o 9600bps que está a
questão, já que as rotinas do ARM são muito rápidas e os bits ainda
estão passeando na linha ...