probleme sur bit1 du portD atmega823P

Jeep56 · Joined: 19 Dec 2015 Posts: 5

bonjour,
je rencontre un phénomène bizarre avec un atmega328P:
voici le début de mon programme:

$regfile = "m328pdef.dat"
'$crystal = 8000000 'j'utilise l'horloge interne à 8Mhz
$baud = 19200
$hwstack = 40
$swstack = 16
$framesize = 32
Config Clockdiv = 1
'-------------------------------------------------------------------------------

Ddrc = &B00111111 ' port C sorties pour 6 servos
Ddrd = &B10000000 ' port D bits 0 à 6 en entrées bit7 en sortie pour led moniteur
Ddrb = &B10000000 ' port B bits 0 à 6 en entrées bit7 en sortie pour led élève
Portc = &H00 ' initialise les sorties servos à l'état bas, mettre une résistance 1k en série
Portd = &B01111111 ' pull-up sur 6 entrées
Portb = &B01111111 ' pull-up sur 6 entrées
....
' le reste du programme consiste à copier les bits 0-5 entrees des ports B ou D vers les sorties 0-5 du port C
'le choix depend de l'état du bit 6 du port D..

Lorsque je teste les entrées en appliquant un 0 sur chacune d'elle, il y a un problème sur la PinD.1:
cette entrée ne passe pas à 0, verification à l'oscilloscope ; 2.8v en la tirant à 0 et de 3.2v au repos.
Le circuit semble reagir à un court-circuit, comme si la PIND,1 etait en sortie forcée à 1.
Comment cette pin peut-elle repasser toute seule en sortie?
Sa deuxiéme fonction est TXD: comment PD1 pourrait-elle être affectée à cette fonction qui est une sortie?
Je n'utilise pas de port serie dans ce programme.
l'ensemble est monté sur un PCB, que j'ai verifié à plusieurs reprises sans rien détecter d'anormal sur le cuivre.
auparavant essayé sur une plaquette d'essai, je n'avais pas remarqué ce defaut sur PD1.
Si vous pouvez m'aider, je vous en remercie.
Jeep

(BASCOM-AVR version : 2.0.8.3 )

Duval JP · Joined: 22 Jun 2004 Posts: 1161 Location: France

Bonjour Jeep56

Ce forum est international, donc SVP ecrit en anglais
This is an international forum, so please write in English
I use Deepl TRaduction to write in an not to bad English
JP
Wink

Duval JP · Joined: 22 Jun 2004 Posts: 1161 Location: France

hi did you use a Arduino to test your program ?

try a very short program with only port D.1
then change to D.3
JP

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Hi
disconnect PD1 from external circuits and try again. If it behaves the same way it will be time to reach into the drawer for a new chip.
I'm also wondering do you by any chance have an arduino bootloader or something similar?
RS

Jeep56 · Joined: 19 Dec 2015 Posts: 5

sorry,
my english is beginner level ...
let me use an online translator.

Jeep56 · Joined: 19 Dec 2015 Posts: 5

I don't use arduino, i still have the old STK200, only for flashing .hex with AVRISP-U.
I plan to switch to Arduino, for more modernity
I made a prototype PCB of my project on a plate with copper bands. I use this on simple circuits like this one.

I think I found the cause, without finding the explanation:
the header of my program is modeled on another program in which I used a serial port on portD.
I realized that I had left the line $ baud = 19200
I deleted it and by magic, everything is back to normal!

Would this line be enough to switch PD1 to TXD output?

Thank you both for your quick response to my call for help.
Smile

jeep

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Hi
Yes, it sets PIND.1 to log.1 in the registry.
RS

MWS · Joined: 22 Aug 2009 Posts: 2262

Jeep56 · Joined: 19 Dec 2015 Posts: 5

thank You SZTRAD:
I confirm after a test of my program by the bascom simulator:
-with the code-line: $ baud = 19200 -> bits 3 (TXEN0) and 4 (RXEN0) of the UCR register (UCSR0B) are changed to 1, following the activation of the serial port
- without this code, they remain at 0.
verification by looking in the ATMEGA328P datasheet:

To remember... Idea

For me it is a solved problem, I will be able to finish my little module.
thank you all
jeep

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Hello MWS
Looks like it.
The following instructions will be carried out
LDI R24,0x18
STS 0x00C1,R24
Or write the bits for RXEN0 and TXEN0. Since the other settings are done before that, the UART is activated.
And then it is valid that "The Receiver will override normal port operation for the RxDn pin when enabled."
So yes according to the simulator this is how it behaves and Mark logically sets the UART as requested by the BAUD command.

RS

MWS · Joined: 22 Aug 2009 Posts: 2262

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Ok
I thought you were serious. I misunderstood "sure?" as your sarcastic remark.
I apologize for the misunderstanding.
The questioner asked, I answered. Nothing more nothing less. Just because you know it doesn't mean everyone knows it. I, for one, didn't know that the Baud directive already made the setup, including HW. That's because I don't use settings I don't need in the program. According to the 1 in the PIND register, you can test if the open UART was left on after the bootloader. I know this because I used it on a device with a bootloader that had this feature.

MWS · Joined: 22 Aug 2009 Posts: 2262

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

[quote="Jeep56"
I think I found the cause, without finding the explanation:
the header of my program is modeled on another program in which I used a serial port on portD.
I realized that I had left the line $ baud = 19200
I deleted it and by magic, everything is back to normal!

Would this line be enough to switch PD1 to TXD output?

jeep[/quote]

yes, this is by design. using this syntax is old but can still be used. i would suggest to use CONFIG COMx however. It can set all the properties of the USART including the baud rate.
there is no magic. the first micros had a simple UART. there was not much to configure so there was not even a CONFIG COM statement.
All that could be set was the baud rate. So the $BAUD was used for that. And when a later micro had 2 usarts, $BAUD1 was added.

In order to use the usart, the TX must be set to output. so this is done automatically.
And any PRINT or other serial command will have the same effect : it will configure the usart including the TX pin.

The PIND register is never altered. the DDR register is used to set the data direction.

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Hi
You don't change it, Mark, it's a HW thing.It comes from the log AND register of the UART
I will try to find the schematic that was sent to me by Atmel once,there you can see why PIND is set.
RS