RP2350: GPIOs are pulled-down upon reset

[SiliconWizard]

According to the RP2350 datasheet and my (limited so far) testing, the GPIOs seem to be pulled down upon reset. So, if you are expecting high-Z, low leakage pins upon reset, look elsewhere.
That looks a bit "unusual". (And was driving me nuts for a few minutes.)

Can people that have used it more extensively confirm this?

[pcprogrammer]

According to the datasheet the RP2040 uses the same setup. Minimum resistance value of the pull down is 50k Ohm and max 80k Ohm for the RP2040. For the RP2350 it depends on the IO voltage where it can be as low as 35k Ohm and as high as 189k Ohm.

It is good to know though, and easily overlooked. 

I wonder what the reasoning behind this is?

[SiliconWizard]

I wonder too. Either this was on purpose (they may have considered that it would cover most use cases while saving external pull downs), or this is a byproduct of the GPIO pad design.

The end result is that if you need high-z GPIOs on reset, you won't have that. And if you need a pull-up instead, you'll have to use a relatively low resistance (around 10k or less) to make sure you'll get a logic high level. That's something to keep in mind. It's not unusual to use 20k to 100k for pull ups or pull downs in many cases to save some power. With the RP2350, it won't work.

[pcprogrammer]

Yes, very true, and based on the design one would think it is not really needed. There are two bits for the pull up / pull down settings, and both can be off. Having one reset to zero and the other to one suggests deliberate by design.

I have not designed real hardware around one of these MCU's, but am playing with an idea, so have to see if this has some impact on the design. At the moment procrastinating with bare metal software development. 
Found the repository of a Douglas H. Summerville with C header files for the RP2040, but decided that these needed some work to make them more useful. https://github.com/dougsummerville/Bare-Metal-Raspberry-PI-Pico
The structs look like they are generated based on the manual, but in a way that make them less useful. Like the inclusion of the different regions for xor, set and clear. To me a more logical setup is a single small structure and assigning the correct base addresses to four sets of the peripheral.

Code: [Select]

//----------------------------------------------------------------------------------------------------------------------------------

typedef struct
{
  __IO uint32      CS;
  __IO uint32      RESULT;
  __IO uint32      FCS;
  __IO uint32      FIFO;
  __IO uint32      DIV;
  INT_CTRL_typedef INT_CTRL;
} ADC_typedef;

//----------------------------------------------------------------------------------------------------------------------------------

#define ADC          ((ADC_typedef *)0x4004C000)
#define ADC_XOR      ((ADC_typedef *)0x4004D000)
#define ADC_SET      ((ADC_typedef *)0x4004E000)
#define ADC_CLR      ((ADC_typedef *)0x4004F000)

//----------------------------------------------------------------------------------------------------------------------------------

It is work in progress though. Did manage to get the on board led to blink with code directly loaded into SRAM via SWD. Makes it a nice system to play with and saves on wearing the FLASH memory with many test writes during development.

[SiliconWizard]

I'm on a project where the RP2350 runs at 420 MHz. (Mostly because I needed that fast for the PIO.)
That requires increasing Vcore to 1.35V and changing the QSPI flash timings a bit.
The MCU reaches about +15-16°C above ambient. Still not too bad.

[cv007]

To me a more logical setup is a single small structure and assigning the correct base addresses to four sets of the peripheral

You can pad out the struct for the rw address range, then use array offsets to access the xor/set/clr registers-

https://godbolt.org/z/vY8zo1o7j

[pcprogrammer]

Wow that is amazing, almost triple the normal speed. Interesting to see how this affects the chip lifetime.

Are you using the ARM or the Risc-V cores?

[pcprogrammer]

To me a more logical setup is a single small structure and assigning the correct base addresses to four sets of the peripheral

You can pad out the struct for the rw address range, then use array offsets to access the xor/set/clr registers-

https://godbolt.org/z/vY8zo1o7j

Thanks, that is an interesting way of doing it.

[cv007]

You can also do what the C++ version is doing with the additional struct, but would have to use -> style pointer access.

A few advantages of this type of register access are that you only have a single struct pointer to deal with, no defines at all, and will also always be forced to choose which register 'group' to access in your peripheral code so you are less likely to make a mistake in using registers in a non-optimal manner-

void enable(){ ADC.CS |= 1; } //with your defines, not optimal as there is no need to RMW ('forgot' I had the ADC_SET register)
void enable(){ adc[SET].CS = 1; } //was forced to choose RW/XOR/SET/CLR, and realized I could use SET here

[pcprogrammer]

You can also do what the C++ version is doing with the additional struct, but would have to use -> style pointer access.

A few advantages of this type of register access are that you only have a single struct pointer to deal with, no defines at all, and will also always be forced to choose which register 'group' to access in your peripheral code so you are less likely to make a mistake in using registers in a non-optimal manner-

void enable(){ ADC.CS |= 1; } //with your defines, not optimal as there is no need to RMW ('forgot' I had the ADC_SET register)
void enable(){ adc[SET].CS = 1; } //was forced to choose RW/XOR/SET/CLR, and realized I could use SET here

I already changed it to make use of the extra structure, so indeed ADC->RW.CS or ADC->SET.CS.

I'm used to the -> style pointer access, so fine for me, and indeed better than what I had first. 

Never to old to learn. 

[SiliconWizard]

Wow that is amazing, almost triple the normal speed. Interesting to see how this affects the chip lifetime.

Yeah, it's hard to tell. As long as it runs stable, the main concerns are probably the core voltage and the die temperature.
The internal regulator can be set up to 3.3V, but they have set a limit at 1.3V, so I suppose that's the limit of what they consider safe. To enable a higher voltage, there is a register bit to disable the limit.
1.35V is still close enough. It probably runs with only 1.3V at 420 MHz, but I based the 1.35V on my own testing plus others' experience.

Another point to consider is the max current the internal regulator can deliver. When you push Vcore and the frequency, of course power consumption increases, and at 420 MHz, with both cores running, it reaches > 100 mA. We can always use an external regulator to be on the safe side.

Are you using the ARM or the Risc-V cores?

ARM cores.

[phil from seattle]

I've never fully trusted the internal 1.1V regulator so I use an external LDO.  Works pretty well and doesn't cost more than the overpriced Abracon polarized inductor.

People should check out the RP2354 which has integrated flash. Works the same as the 2350 and saves some money given the cost of flash these days. It drops on to the same board layout as the 2350.

[SiliconWizard]

I've never fully trusted the internal 1.1V regulator so I use an external LDO.  Works pretty well and doesn't cost more than the overpriced Abracon polarized inductor.

They haven't fixed this "issue" in the A4 revision, so yes, it still applies. The Abracon inductor they recommend is not the only reference that works, of course, but you have to be careful with orientation when placing it on PCB. "Polarized" here is of course not in the electrical sense, but magnetic. There's a short explanation here from Murata:  https://www.murata.com/en-eu/products/inductor/overview/learn/basic/direction-mark
Abracon is not the only manufacturer which shows the prefered direction on the package.

One downside of using an external regulator is that you can't really take advantage of some of the low-power modes which automatically shut down / enable the internal regulator. If you don't care about low-power modes, then it's ok. That's something you could always handle with a GPIO instead, manually, but it won't be as fast and it will require care to make it fully safe.

[westfw]

To me a more logical setup is a single small structure and assigning the correct base addresses to four sets of the peripheral.

Why do you find "small" structures "more logical"?

It's not like these are ever instantiated in user memory (I hope); they just map to the actual peripheral layout.
(Yeah, I don't particularly like having the xor/set/clr registers in a peripheral selected by higher order bits instead of low order bits (having reg/xor/set/clear being consecutive, as on many other implementations.  It seems it might interfere with the smaller indexed addressing modes, for one thing.)

The array index method is "interesting", though.  It gives you an easy programatic way of getting to the functions...

[pcprogrammer]

To me a more logical setup is a single small structure and assigning the correct base addresses to four sets of the peripheral.

Why do you find "small" structures "more logical"?

In this case it is about seeing either a small set of registers for a peripheral or see a big list with four copies of the same set of registers, but with the names starting with xor_, set_ or clr_.

The modification cv007 brought to the table makes it even better, and with an IDE that shows the members of a struct, one can't miss the other available sets than just the original read write version. This setup gives the most logical setup for the RP2040/RP2350 peripherals.

Code: [Select]

//----------------------------------------------------------------------------------------------------------------------------------
//Structure definitions
//----------------------------------------------------------------------------------------------------------------------------------

typedef struct
{
  __RW uint32      CS;                            //Control and status register
  __R  uint32      RESULT;                        //Result of most recent conversion
  __RW uint32      FCS;                           //FIFO control and status register
  __R  uint32      FIFO;                          //Conversion result FIFO
  __RW uint32      DIV;                           //Sample rate divider
  INT_CTRL_typedef INT_CTRL;                      //Interrupt control and status registers
       uint32      RESERVED[(0x1000 / 4) - 9];    //Padding up to the next range of registers (XOR, SET and CLR)
} ADC_reg_typedef;

typedef struct
{
  ADC_reg_typedef RW;
  ADC_reg_typedef XOR;
  ADC_reg_typedef SET;
  ADC_reg_typedef CLR;
} ADC_top_typedef;

//----------------------------------------------------------------------------------------------------------------------------------
//Base address coupling
//----------------------------------------------------------------------------------------------------------------------------------

#define ADC                           ((ADC_top_typedef *)0x4004C000)

//----------------------------------------------------------------------------------------------------------------------------------


[jheissjr]

An example for the example.
 

Code: [Select]

#define ADC                           ((ADC_top_typedef *)0x4004C000)

ADC.SET.FCS = 1<<5;   // set bit five of the FIFO register

Compiles to -
(unint_32_t *)(0x4004C000 + 0x2000 + 0x08) = 1<<5;


[grx]

Confirmation of this issue can be obtained from Luke Wren available on mastodon.

[jheissjr]

This should swap the bit access register and control register if the style is preferred.

Code: [Select]

typedef struct
{
  __RW uint32 RW;
  uint32      RESERVED0[(0x1000 / 4) - 9];   
  __W uint32f XOR;
  uint32      RESERVED1[(0x1000 / 4) - 9];   
  __W uint32 SET;
  uint32      RESERVED2[(0x1000 / 4) - 9];   
  __W uint32 CLR;
} ADC_reg_typedef;

typedef union
{
  ADC_reg_typedef CS;                         
  struct {
    uint32 RESERVED[1];
    ADC_reg_typedef RESULT;               
  }
  struct {
    uint32 RESERVED[2];
    ADC_reg_typedef FCS;                   
  }
  struct {
    uint32 RESERVED[3];
    ADC_reg_typedef FIFO;                 
  }
  struct {
    uint32 RESERVED[4];
    ADC_reg_typedef DIV;                 
  }
  struct {
    uint32 RESERVED[5];
    ADC_reg_typedef INT_CTRL;         
  }
} ADC_top_typedef

#define ADC     ((ADC_top_typedef *)0x4004C000)

ADC->FSC.CLR = 1<<5;    // clear bit five of the FSC register 

[westfw]

So who wants to write the python code to generate these styles of definitions derived from the .svd file?(The whole RW/Set/Clear/Xor scheme is common to many (all?) of the rp2xxx peripherals, isn't it?)