Using AT90CAN128 as a drop in replacement for ATmega128

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello folks,

I am using an AT90CAN128 to replace an ATmega128 in an existing design. The hardware compromises 32KB of external memory and a RealTek NIC at 0x8300. The OS used is uIP and Nut/OS.

I am experiencing problems which I haven't been able to track down but it relates to the AT90CAN128 chip. Code compiled with the I/O header files for atmega128 runs on atmega128. Same code compiled with the I/O header file for at90can128 crashes after a while. Same hardware. Tried gcc and icc compiler, same result.I scrutinised the code for all access to registers and we always use the menmonics from the I/O header files.

The issue can relate to hardware, software, compiler or the new chip. Of course it will be very likley the software but I like to ask the question if anybody else has experienced stability problems when using the AT90CAN128?

Thanks,
Henrik

Last Edited: Sat. Apr 2, 2005 - 06:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel have changed some of the registers for CAN128....so check the header file.
I have been using CAN128 for about two months, so far I've not experienced any major problems (except with EEPROM)

are you using EEPROM in/from the NUTOS?
I know in avr-gcc there is a problem, so you will need to write your own EEPROM read/write routines.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for the response.

I am aware of the EEPROM issue with avr-libc and tried both commenting the relevant code and providing my own replacment ones.

Q: Are you using external RAM in your design? If yes what kind of latch?

Q: WIth reagrds to the registers, are you aware of any discrepancies between the datasheet 12/04 and the avr-libc header files?

Henrik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using the JTAG interface or any of the ADC4 through ADC7 pins? Because the JTD bit was moved from the mega128 MCUCSR register to the can128 MCUCR register, the can128 data sheet example now has a bug. When changing the interrupt vector locations, IVCE is a 4 clock cycle timed operation. However, the JTD is also a 4 clock cycle timed event. Now that both JTD and IVCE both share the same register, the data sheet page 60 (12/04 version) interrupt vector change example will always set the can128 JTD to zero and enable the JTAG pins (if the JTAGEN fuse is programmed). I'm not sure what these four AVR JTAG pins will do if the JTAGEN fuse is not programmed. I already reported it to ATMEL. Maybe your C complier also overlooked this change.

You can also have problems like JTD is a valid name in both header files. MCUCSR changed names to MCUSR in the can128. However, because JTD moved, you can not get away with setting JTD in the MCUSR. Now you have to set JTD in the MCUCR register for the can128. This is just one example of how you really mess up your can128 program by just expecting everything to work the same way by changing header files.

Some things like the mega128 XDIV register was replaced in the can128 by CLKPR which works differently than XDIV. The Extended Standby sleep mode is gone.

Some mega128 registers have changed names and bit assignments in the can128 (ETIMSK, ETIFR, XMCRA, TIMSK, TIFR, MCUCR, MCUCSR, ASSR, etc.). MCUCR should be of interest to you because some of the external memory interface control bits were moved to the XMCRA register (including the external memory enable). The timer prescaler control was also moved to a new register. The SFIOR bits have been spread around the three GTCCR, ADCSRB and MCUCR registers. I do not see how you can just change the SFIOR register name and get these bits to work in a can128 program. I doubt the C language compliers are sufficiently abstracted to carry out the correct bit assignments for registers like these that have had their bits split up and moved around to new or different registers.

Because the I/O registers had address changes, some of the mega128 registers can not use the bit set or bit reset instructions in the can128 and vice versa.

Most important of all, many interrupt vectors have changed locations. I assume you C complier is handling this correctly?

Even in C, the change from mega128 to can128 is not as simple as changing header files. Check out AVR application note #096 to see where your mega128 code has can128 problems.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks again for the quick reply. Maybe I simplified it in my first reponse when I said I changed only header files. I checked the code for register usage and made sure only mnemonics are used and the bit mnemonics are still valid for the particular I/O register. The app note AVR096 is my bible for doing this. In some areas I am using conditional compilation because of the different registers used for a certain function like enabling the XRAM.

As the system is using only one timer for tick generation, the XRAM interface, a UART and one external interrupt the changes were limited to a few places.

The application starts up ok but its when multiple threads are running Nut/OS), dynamic memory is allocated and de-allocated, network interrupts coming in, context switching takes place, then it eventually chrashes. And this is all I know so far. All simple examples and tests do work if run by itself. The tricky part for is to isolate the problem so I understand what leads to it.

I do a continous memory check on a block in the heap. And it happens after a while that the check fails for one iteration. Sounds very much like context switch problems or memory access problems. That's why I asked the question about the external memory interface and the latch.

Henrik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I assume you ported the Nut/OS source to the can128 and recompiled it. Off the top of my head, I can not think of anything obvious that should not work with a good port.

Programming the CLKO fuse will be a problem if you use A15. If you use Timer2 with a watch crystal (used to be Timer0), then double check the new Asynchronous programming bits.

I do not know exactly how Nut/OS uses its timer. From your description it sounds like it is running the scheduler. Try calculating the time to the first AVR timer overflow if there is any chance it might coincide with the crash timing.

Since you are crashing, try the old standby of reading the reset flags in the MCUSR register at startup, save the value and clear MCUSR. It adds just a little more debug information to crash situations.

Just for grins, try increasing your memory wait state timing (unless this particular circuit has been already been checked with a mega128 chip). Speaking of which, are you sure this particular circuit board has no soldering/trace problems or shorts. Shorted or open address lines make for frustrating software debugging :(.

Since you are using timers in real time and a complex peripheral, software based simulators will not be of much use. Either JTAG or old fashioned ICE will be your only real choice. Still, your are wading into the deep end with an RTOS and network interface. Try testing with the network cable unplugged to help simplify the overall level of activity.

The only can128 problem I have found so far is the JTD problem in the IVCE code example.

There is the annoyance of the new CKDIV8 default programmed fuse which will probably account for lots of “help my can128 UART does not work or my timer is not right” posts in the future. I guess they had to come with a replacement for the now gone mega103 default compatibility fuse and the constant problems it caused for the unwary :).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi folks,

first thank you for all the hints and suggestions. Although I took most of them already into account.

I managed finally (after digging deep into thread context switching code) to create a simple small program which reliably reproduces the issue. You find it attached. See source code comments how to compile. I invite all AT90CAN128 users with a board fitted with XRAM to try it. I am very curious to know the results.

Findings:
- The issue relates to boards populated with the ATCAN128 CPU only. Boards populated with the Atmega128 do not show the issue.
- The issue only shows if the SP is located in XRAM (32KB are fitted in my design).
- The issue only shows if interrupts are enabled and an ISR is executed
- I fitted a "proven" Atmega128 evaluation board (Ethernut 1.3f) with the AT90CAN128 chip and it shows the issue as well
- Reducing clock speed to 8 MHz and insertion of wait states did not change a thing
- Removing the network controller from the board did not change a thing
- We tested two WinAvr versions with different gcc and avr-libc versions and also Imagecraft 6.31A. Issue is tool independent.
- The issue is completely unrelated to any OS or TCP/IP stack used. It just used to happen that Nut/OS context switching model will have SP pointing to XRAM.

Conclusion:
- The issue only relates to the position of the stack pointer in XRAM space, interrupts enabled and the AT90CAN128 CPU.

Question:
Now I like to ask my fellow forum members, has anybody tried using the ATCAN128 chip with SP pointing to XRAM and at the same time using interrupts? I REALLY LIKE to know.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello fellow AT90CAN128 users and AT90CAN128 users-to-be,

here is the explanation:

After some email correspondence with Atmel, they now have confirmed a bug to be on the chip and the issues I experienced and described in earlier posts are related to this bug on the silicon.

What I cannot believe is that I had to be the first one discovering this
bug as I could not find any reference to it in any of the AVR related
forums.

Until an official Errata is published, please refer to the following bug
description:

Quote:
Hello Mr ...,

I confirm the bug on our Product AT90CAN128.
The following description will be added in the next version of the
datasheet.
-------------------------------------------
Miss-functioning when code stack is in XRAM
If either an "IN" or an "OUT" instruction is executed just before an
interrupt occurs and if the stack pointer (SP) targets the XRAM, the
instruction is
executed twice. Because the other instructions are not from the same
class,
it seems that only "IN" and "OUT" instructions are concerned.

Problem Fix/Workaround
Map the code stack in SRAM.
-------------------------------------------
We confirm that the only workaround is to map the stack in the internal
RAM.

The Design correction will be done as soon as possible.

Technical Marketing
Atmel - Nantes - France