ATMEGA16A PORTB Conflicts?

[Hydro-Jeff]

Hello All,

I'm working with the ATMEGA16A & ATMEGA8515L. The latest patch for FC6 fixed most of the problems I have had while trying to develop a COMM interface (RS232) to control the on-board hardware, but I still have one issue left. It seems that there is a conflict with the alternate PORTB functions. When I use PORTB as an output port the COMMs stop working..... The odd behavior may be because the port is not set up properly??? If I move my outputs to PORTC this behavior disappears. Has anyone out there observed this? If so, is there a fix?
I'm not very good with C, so I can't tell if there is a conflict in the chip setup or not. Any help would be greatly appreciated.

Thank you,
Hydro-Jeff

[Benj]

Hello,

Are you using the output icon to output to PortB? If so then you might need to enable masking to avoid switching the data direction of the UART pins.

Otherwise are you using a component on PortB? If so which component and what pins are you using?

[Hydro-Jeff]

Hi Benj,
Yes I am using the output icon to output to portB. Right now I'm not using any specific component on portb, just testing commands for COMM interface.
Also, I thought the TX/RX were on portD.0&1. The data sheet has a section on how to "override" the alternate functions of portb, but I'm not sure I completely understand what I would have to do via FC6 to accomplish this....

Thanks,

Hydro-Jeff

[Hydro-Jeff]

Hi Benj,
Thanks for the response. I'm re-posting my reply as I don't see the first one. Just got back from Department meeting.
I did indeed use the icon to output to portb. I don't have any devices connected to portB, just the LEDs from the STK500 development board.
I thought the UART is on portD 0 & 1?? I did see a section in the datasheet that explained how to disable the alternate functions for portb, but I'm not sure how to do that via FC6.
What is the default setup for the hardware? I'm sure it is in the setup file, but I just don't understand what I'm looking at.

Thanks again,
Hydro-Jeff

[Benj]

Hello,

Hmm your right the PORTB output should not be effecting the UART if it is on PORTD. I'll have a look at the datasheet and see if I can figure out what's going on here.

[Benj]

Hello,

Apparently the ATMEGA16A will default to 1MHz internal osc operation by default.

Have you manually set the fuses to something else?

The easiest way to confirm if this is working is to use the 1 second flasher approach: http://www.matrixmultimedia.com/wiki/in ... ED_flasher

Once we have this working correctly it may be easier to diagnose what is going wrong with the UART comms.

[Hydro-Jeff]

Hi Benj,
I have the 8MHz int osc selected. the blink test works fine. I did have to use 1000msec as the delay. I receive compiler errors when I choose 1 sec for the delay... I find that odd as well.
I program the device with the JTAGICE3 through Atmel Studio 6.1. I have verified via JTAGICE3 that the SUT_CKSEL is correct.

Thanks,
Jeff

[Benj]

Hello,

Is it possible for you to send me your project so far. If you can send it so it is replicating the 1s compile error then that would be fantastic. Think this may be related to a bug that has already been fixed but not released yet.

Just noticed there is no definition file for the ATMEGA16A device, are you using the ATMEGA16 instead?

Here is an FCDX if you want to give this a go, not many changes but at least it will be passing the right device flag to the compiler.

[Hydro-Jeff]

Benj,

I know you may find this hard to believe, but when I change the delays back to 1 sec and re-compiled it work without errors. I loaded it into the chip and the blink program is working properly.
I have noticed that I get compiler errors for delays from time to time depending which scale and value I use. The COMMS were not working either the first couple of times I tried compile and program a simple send/receive program..... This too is now working. I don't think I'm going crazy.... I'm going to try a program to write to outputs AND send/receive on the COMMs and see if I can break it again. If I do, I'll upload it.

Jeff

[Hydro-Jeff]

Benj,

This program compiled without error, after programming to chip, it worked for a few loops then stopped working........

Let me know if you find anything.

Jeff

[Hydro-Jeff]

Benj,

After downloading your file and re-starting FC, I recompiled the program I just uploaded and got this compiler result....
See attached.

Jeff

[Hydro-Jeff]

Hi Benj,

Any luck with the datasheet dive? I've been looking into it and it does seem to me that this could be a setup issue. Do you have a lot of Atmel users?

Thanks,
Jeff

[Benj]

Hello Jeff,

I think I have found and fixed the issue now. Give this FCDX file a whirl and hopefully it will let you compile correctly.

ATMEGA16A.fcdx

(18.08 KiB) Downloaded 270 times

Let me know how you get on.

[Hydro-Jeff]

Benj,

Thanks for your efforts to resolve this problem, but I still get the same results with the program that I up-loaded to you yesterday. I change the output port from C to B and back again to no avail.
When I use portC the loop runs about 4 times before the COMMs stop working. When I use portB the COMMs never work. If I use the program with COMMS only (no R/W with I/O) UART seems to work properly.

Don't give up on me! I'll keep digging on my end as well.

Jeff

[Benj]

Hello Jeff,

Can't really understand why this would be happening but here are a couple of pointers.

1) The ReceiveChar(255) will wait forever for an incoming character. Maybe changing this to 100 or 200 would be more suitable to avoid sitting and waiting forever.

2) You only want to re-transmit the data if it is valid so a decision to see if the incoming value is less than 255 might be useful.

Here is a slightly modified program, have a go and let me know how you get on.

ATMEGA16.fcfx

(5.95 KiB) Downloaded 227 times

[Hydro-Jeff]

Hello Benj,

Downloaded your version of the program and got an error trying to open it..... "Failed to open document. Attribute <start> is not found"

Thanks,
Jeff

[Hydro-Jeff]

Hi Benj,

If I write all 0s or FD to portB after each rx/tx loop the COMMs work without error. Also, I have noticed that the auto clear watchdog status can cause compile errors depending on which delay time you choose. For example, a 10mSec dealy will not compile with the box checked, but a 500mSec delay will......

I still believe that my problems are due to setup issues....
Don't know how much longer I can spend $$ on trying to make this work. Do you have known working examples (UART & I/O together) of code for this chip? If so can you send them to me?

Thanks,
Jeff

[Hydro-Jeff]

Hi Benj,

Ver 6.06 seems to have solved many issues, including this one. Thanks. Good work!

Jeff