### rom_i2c funcs?

Advanced Users can post their questions and comments here for the not so Newbie crowd.

Moderator: eriksl

### Re: rom_i2c funcs?#92286

By RBMK
#92286
eriksl wrote:More notes:

- the stack pointer [a1] is lowered by 32 bytes, 8 32 bit words.
- any argument passed on the stack, is therefore on 32(a1) or higher
- it looks like no arguments are passed over the stack, that seem to be unusual for xtensa (even on call0)
- at 0(a1) = a3 (saved register)
- at 4(a1) = a0 (saved register)
- at 8(a1) = a12 (saved register)
- at 12(a1) = a13 (saved register)
- at 16(a1) = a14 (saved register)
- interesting what 20(a1) - 28(a1) is used for...
- a5 is a 32 bit parameter to the function, it's not set anywhere in the function. It must be either an integer (probable) or a float (less probable). a5 is "moved" to a12 and a12 is then used in a calculation.
- something is also done with a2 and a4, looks also like 32 bit values
- a3 is never used though (only as a result)
- this is interesting:
Code: Select all`4000797c:   110260     slli   a0, a2, 104000797f:   040a         add.n   a0, a4, a040007981:   1120e0    slli   a2, a0, 2`

it calculates a0 = ((a2 << 10) + a4) << 2. The last shift will probably turn an "index" into a pointer into an array of 32 bit values. Yep, confirmed, they're not integers though, but floats (also 32 bit).
- also there are three s8i instructions, all of them write a single byte from a2 to (a12) with an offset of 0, 1 or 2. Maybe a12 contains a register address at this point. There are no other relevant writes to memory addresses. a12 is set from a5 and definitely not calculated in the function...

a float parameter? stranger, in my for loop i use integer. i cant try the same with floats bcs i still have no idea how to enable the use of newlib-nano to use floating points

### Re: rom_i2c funcs?#92287

By RBMK
#92287
eriksl wrote:Interesting, I will look again.

In the old days I used to have an 68000 machine that was rated at 16 Mhz, but the clock could be set to 24 Mhz too. The situation was a bit comparable to this, it would run fine for some time, but then strange things would be starting to happen. I think we really hit the "hard limit" here. At some point the electrical capacities between the signal lines will grow to large (for the given frequency) and then signal deformation will happen, causing tranmission errors (within the die). Also the die will start using much more power at higher frequencies, if it's not designed for it. I am not even worried about heat generation, but it might cause dips in the (local) power supply (on parts of the die itself).

Yhea, maybe, maybe is an unstable formula of registers? or maybe we should try complete disable PLL divisior register? becouse, if you think about it, the PLL is already running at 1040 MHz, so the dye probbably can handle that frequency, think about the 2.4GHz WiFi

### Re: rom_i2c funcs?#92288

By eriksl
#92288 Die, maybe, but the processor part probably not.

Also it's quite common to have a very high starting frequency to be able to select fine grained frequencies. It does not mean the hardware can actually handle it as-is. After the PLL probably various dividers are used. That's how it is on microcontrollers I am used with anyway (ATmel).

Anyway I read somewhere that 400 Mhz is the design frequency of the processor, I don't think you should be targeting for any higher, it will probably burn the die sooner or later.

### Re: rom_i2c funcs?#92289

By RBMK
#92289
eriksl wrote:Die, maybe, but the processor part probably not.

Also it's quite common to have a very high starting frequency to be able to select fine grained frequencies. It does not mean the hardware can actually handle it as-is. After the PLL probably various dividers are used. That's how it is on microcontrollers I am used with anyway (ATmel).

Anyway I read somewhere that 400 Mhz is the design frequency of the processor, I don't think you should be targeting for any higher, it will probably burn the die sooner or later.

Well, i find out that you can disable the cahce stuff and i2s stuff without loose stability on slower frequencys, now when i try use it with 390 MHz, i get 40001f56 and some other errors related to FLASH, so my best theory is that we hit the FLASH frequency divider top, passing i belive ~378 MHz on CPU, the FLASH cant divide anymore. But i guess that is i at last make work 378, i would be happy!