[ATmega 0] The evnt system register names mystery

[Simon]

Yep, new section in the datasheet same old crap!

So let's make a start not that I need them: STROBEA and STROBEB. Contrary to the documentation no such registers, variables or fuck knows what exist!

the magical iom4809.h file is also clueless only mentioning STROBE which is a valid struct variable. Do I assume another massive mess from the masters of chaos considering there are only 8 event channels so why have provision to strobe 16 or did they forget to clean up someone else's datasheet they copied from when they recreated the Xmega's and pretended they came out with new chips?

[T3sl4co1l]

I noticed several desyncs between datasheet and header on the XMEGA as well.  I assume the datasheet is correct and the header is lacking.  Easy enough to correct, put the missing lines into your own header.

Likewise, I found some lines that are probably from the A series (XMEGA64A1 or such) that aren't present in the D series I was using.  These can be removed with #undef.

Mind, for portability, you want to put the device-specific defines into a device-specific section, and not use them otherwise.  Use the IO header's def to detect this (put an #ifdef _AVR_ATmega4809_H_ ... #endif, or whatever it is, around the section).

Example, the D3 version has the register ADCA.CH0.SCAN (0x226) which is missing from the header.  Observe the following log:

Code: [Select]

Active Load, by Tim Williams, Jun 21 2018
Commands:
Any key          Start console interface
?                Display this message
R <sram> [byte]  RAM <read>/[write] addr
S <reg> [val]    SPI <read>/[write] reg
I                Initialize LCD (SPI)
C                Clear LCD (SPI)
G                Play Raycaster

>r 226
RAM at: 226h = 45h
>r 226 0
Write: (226h) <= 0h
>r 226
RAM at: 226h = 0h
>r 226 ff
Write: (226h) <= ffh
>r 226
RAM at: 226h = 9fh
>r 226
RAM at: 226h = 7fh
>r 226
RAM at: 226h = afh
>r 226 45
Write: (226h) <= 45h
>r 226
RAM at: 226h = 45h
>r 226
RAM at: 226h = 55h
>r 226
RAM at: 226h = 25h

I have a RAM read/write function on the serial console, making it easy to verify things like this.

As it happens, the ADC is running, so the high bits are cycling in hardware.  That's why the read is inconsistent, it depends on what time I hit enter.  The low bits are static.

It's certainly not zero, as you might expect from it being unlisted in the header; for example, 0x227 is a reserved port, and is dead on the bus:

Code: [Select]

>r 227
RAM at: 227h = 0h
>r 227 ff
Write: (227h) <= ffh
>r 227
RAM at: 227h = 0h
>

Writing 0xff into the port does nothing, it remains 0.

I do wonder how many reserved ports are actually implemented (i.e., undocumented ports), suppose I could make a table and do a scan some time.

Tim

[Simon]

I'm not sure i follow you. Presumably if i try and add my own register definitions I need to know the memory locations of those registers as ultimately this is what it's all about in the end, writing numbers to an address location. I can find no meaningful information in the datasheet. All register address locations are offsets and on every peripheral the offsets start at 0x0... they can't all be starting from the location so there must be a further offset, ah just found that, page 43.

So now what, do i need to define the register name as the periphery offset + the register offset?. I don't even know how to do that in these new fangled header files where instead of just use address numbers that are defined with names they have created these weird variables. I think I'll pass for now.

[Simon]

I was going to try out of desperation the Atmel start bullshit but on trying to setup TCA0 in split mode I discovered no split mode settings...... What a joke.

[T3sl4co1l]

I did it this way:

Note that all registers (that weren't forgotten, anyway?) are still named, just not descriptively.

Code: [Select]

/*  Missing ADC register definitions  */
#define TEMP reserved_0x07
#define SAMPCTRL reserved_0x08
#define ADC_SAMPVAL_bm 0x3f
#define ADC_SAMPVAL_gp 0
...

The ADC struct contains named registers, and "reserved" registers.  I'm not redefining the struct, just using what they've already provided, and using a correct name for it.

I haven't seen if there is a case where the struct itself is completely wrong and needs to be redefined (something which cannot be done in C).  Possibly you could shuffle the namespace with some defines, but...ehhh...

This is later used in my code as absolutely normal syntax:

Code: [Select]

// ADC channel 0, interrupt, PA1 first input, PA6 last input
ADCA.CH0.CTRL = ADC_CH_INPUTMODE_SINGLEENDED_gc;
ADCA.CH0.MUXCTRL = ADC_CH_MUXPOS_PIN1_gc;
ADCA.CH0.INTCTRL = ADC_CH_INTLVL_MED_gc;
ADCA.CH0.SCAN = (5 << ADC_CH_COUNT_gp); // Scan 5+1 = 6 channels (VO, IO, TMP, POT1, POT2, POT3)

Tim

[Simon]

So something like:

Code: [Select]

#define CLKCTRL_MCLKCTRLA  _SFR_MEM8(0x0060)

is assigning the name to the memory address. I take it _SFR_MEM8 is their cosy way of saying that that it's a number in their 8 bit memory space?

[Simon]

#define EVSYS_STROBE  _SFR_MEM8(0x0180)

This is what the datasheet calls STROBEA... STROBEA has a an offset of 0x00, the event system adress space starts at 0x0180.
The next listed address is 0x0190 so in theory the address of 0x0181 is still undefined and would be STROBEB. But I am still confused as to why there are 2 strobe registers. There are 8 event channels, why do I need 16 strobes? i think the datasheet is wrong, likely copied from an xmega datasheet with 16 event channels.

[andersm]

To be fair, the datasheets are still marked as preliminary.

[Simon]

Well they are selling chips! I can't help their laziness. If you want to use them you need to have a correct datasheet. It is pointless selling chips if there is no accurate information to use them. The datasheet is cryptic at best and often incorrect. They have done the mammoth task of designing the chip (allegedly), is it that more difficult to get some text in the datasheet right? apparently yes.

This datasheet has been out a while now, I suspect I am not the first person to find these errors. Apparently for the sake of their own pride many of us have to discover the same thing separately and collectively go through hours of unnecessary work when they could update datasheet every couple of weeks . I mean do they want anyone to use these chips?

[Simon]

Of course I do not know if the header file is incorrect or the datasheet.

[andersm]

You've been doing this long enough to know that picking a brand-new part is always going to be a gamble. Still, seeing as you've volunteered for the task, I hope you're reporting your findings to Microchip.

[Simon]

How do I report anything to microchip? And actually I'm not that experienced.

[andersm]

See this article. It does require you to register with Microchip's support system. I've found their support fairly responsive when reporting issues, at least when provided with a clear and detailed report, but YMMV.

[Simon]

See this article. It does require you to register with Microchip's support system. I've found their support fairly responsive when reporting issues, at least when provided with a clear and detailed report, but YMMV.

Your right, and they did respond in an hour or so:

Hello Simon,

Microchip Engineering Support has added comments to support Case 00325606.

 **** Microchip Comments Begin ****
Hello Simon,

Thank you for reaching out to us! I've looked into the ATmega4809 part pack and family data sheet, and you're absolutely right about there being an inconsistency. I have reported a bug to our documentations department, and will further investigate to find out what is correct.

I'll get back to you when I have an update.

Best regards,
Amund Aune
Applications Engineer
 **** Microchip Comments End ******


Problem Description:
Pages 124 and 125, the event system strobe registers STROBEA and STROBEB. These do not correspond to the device. There are 8 event channels, Why have 16 strobe signals when there is only one per channel.

The header file appears to only include a STROBE register.

[Simon]

It would also appear that it is not necessary to reference the struct variables to control the registers. These people do it all in reverse. The stuff at the start of the chips header file is actually all of their middleware crap for the crappy atmel start that is incomplete bloatware. The actual register name definitions are lower down, I take it the following looks a bit more civilized:

Code: [Select]

/* EVSYS - Event System */
#define EVSYS_STROBE  _SFR_MEM8(0x0180)
#define EVSYS_CHANNEL0  _SFR_MEM8(0x0190)
#define EVSYS_CHANNEL1  _SFR_MEM8(0x0191)
#define EVSYS_CHANNEL2  _SFR_MEM8(0x0192)
#define EVSYS_CHANNEL3  _SFR_MEM8(0x0193)
#define EVSYS_CHANNEL4  _SFR_MEM8(0x0194)
#define EVSYS_CHANNEL5  _SFR_MEM8(0x0195)
#define EVSYS_CHANNEL6  _SFR_MEM8(0x0196)
#define EVSYS_CHANNEL7  _SFR_MEM8(0x0197)
#define EVSYS_USERCCLLUT0A  _SFR_MEM8(0x01A0)
#define EVSYS_USERCCLLUT0B  _SFR_MEM8(0x01A1)
#define EVSYS_USERCCLLUT1A  _SFR_MEM8(0x01A2)
#define EVSYS_USERCCLLUT1B  _SFR_MEM8(0x01A3)
#define EVSYS_USERCCLLUT2A  _SFR_MEM8(0x01A4)
#define EVSYS_USERCCLLUT2B  _SFR_MEM8(0x01A5)
#define EVSYS_USERCCLLUT3A  _SFR_MEM8(0x01A6)
#define EVSYS_USERCCLLUT3B  _SFR_MEM8(0x01A7)
#define EVSYS_USERADC0  _SFR_MEM8(0x01A8)
#define EVSYS_USEREVOUTA  _SFR_MEM8(0x01A9)
#define EVSYS_USEREVOUTB  _SFR_MEM8(0x01AA)
#define EVSYS_USEREVOUTC  _SFR_MEM8(0x01AB)
#define EVSYS_USEREVOUTD  _SFR_MEM8(0x01AC)
#define EVSYS_USEREVOUTE  _SFR_MEM8(0x01AD)
#define EVSYS_USEREVOUTF  _SFR_MEM8(0x01AE)
#define EVSYS_USERUSART0  _SFR_MEM8(0x01AF)
#define EVSYS_USERUSART1  _SFR_MEM8(0x01B0)
#define EVSYS_USERUSART2  _SFR_MEM8(0x01B1)
#define EVSYS_USERUSART3  _SFR_MEM8(0x01B2)
#define EVSYS_USERTCA0  _SFR_MEM8(0x01B3)
#define EVSYS_USERTCB0  _SFR_MEM8(0x01B4)
#define EVSYS_USERTCB1  _SFR_MEM8(0x01B5)
#define EVSYS_USERTCB2  _SFR_MEM8(0x01B6)
#define EVSYS_USERTCB3  _SFR_MEM8(0x01B7)

Would be nice if they somewhere explained what they planned and made available.

[T3sl4co1l]

They provide MEGA-style flat named registers for backwards compatibility, but using them, you lose the portability of being able to remap devices in software without worrying about each device being slightly different (e.g., consider TC0, TC1 and TC2 on the mega32).

The point is to have, say, four SPI devices, all laid out in precisely the same way, with identical register offsets, names and bit functions.  You only need provide the register base address to the driver code, and it knows the rest.

Tim

[Simon]

But i thought that was the point of header files. They map the names to the addresses so that the TCB0 names can be used on any device but providing the correct header file is loaded the names will point to the same registers in different numerical addresses on a different addresses.

[T3sl4co1l]

Well, yeah, you would invoke such a function as:

doDeviceOperation(&TCB0, param1, ...);

Tim

[Simon]

#define EVSYS_STROBE  _SFR_MEM8(0x0180)

I would expect "EVSYS_STROBE"  to be common across the range and that particular peripheral no matter the device, so if I always use it in my code it will work. On the 4809 it corresponds to address 0x0180 and on other devices it may correspond to a different address. But if I always use the standard name in my functions it will always point to the correct address for that peripheral on any device where i use the correct header for the chip.

If you create a project with Atmel start you find all of the struct stuff and other crap called by the middle-ware files.