SAME70N21: PD7 & 7 pinned as driving high level output

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

On J variant of SAME70, used as PIO PD7 & PD8 are  not controllable and are furthermore both active high level.

 

Using debugger on each of these lines, voltage is indifferent: 3.2V Level is high and driving even after reset

 

int main() {

   ioport_init();                                                        
   pio_configure_pin( PIO_PD8_IDX, PIO_TYPE_PIO_INPUT);                                                  
   pio_configure_pin( PIO_PD8_IDX, PIO_TYPE_PIO_OUTPUT_0);                                               
   pio_configure_pin( PIO_PD8_IDX, PIO_TYPE_PIO_OUTPUT_1);                                                
   ioport_set_pin_dir( PIO_PD8_IDX, IOPORT_DIR_INPUT);                                                    
   ioport_set_pin_dir( PIO_PD8_IDX, IOPORT_DIR_OUTPUT);
   ioport_set_pin_level( PIO_PD8_IDX, 0);
   ioport_set_pin_level( PIO_PD8_IDX, 1);

   :

 

(I.e. using  braces and belt).

 

PD8_IDX confirmed to value 104 using debugger and crossmatched with ASF source (i.e. excluding possible build config missmatch):

#define PIO_PD8_IDX               104

 

Another pin PD31 in the same group works fine.

 

What am I missing here?

We've seen this/similar issue on N variants for PB5. (On N variants PD8 works however).

 

Setup:

  • For debugging HW purposes, pins have been lifted from the PCB and are now NC. I.e. nothing can drive the levels except the MCU.
  • Reset is via  jtag debug command (OpenOCD soft_reset_halt)
  • No secondary boot-loader in-between, i.e. no SW except possibly ROM-boot could have affected pin-function state/settings.
This topic has a solution.
Last Edited: Mon. Aug 17, 2020 - 02:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it possible that the pins on your particular chip may have been damaged by your handling or your circuit?

 

I have a product using the ATSAME70N21 chips, and have used PD7 and PD8, and the pins behave as documented.

Josh @ CIHOLAS Inc - We fill the gaps from chips to apps

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

Hi Josh, great to know!

 

As much as I would like not to, yes - it is possible. We've been very careful and HW-error is usually the last thing to look at when everything else is exclude. I come from an industry where HW bugs are extremely rare, but it happens. Both handling and design possibility is now considered and are being investigated.

 

As mentioned we've had similar issues with PB5 on both N and J variants on different designs and different boards and different teams, which to me implied less likelihood of HW error. But these two issues may be completely unrelated which is why experience from others are extremely valuable. Thank you!

 

On a related note:

What happens if the ROM (or any secondary) boot-loader sets pins in certain mode (alternate function or PIO_TYPE_PEREPH_X), how to assert that the pin is turned back into it's primary function? Is ioport_init(); enough? Documentation is somewhat unclear.

 

(Secondary bootloader is excluded from design atm, application is flashed into 0x00400000).

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

Microchip lists GPIO pins that may be configured during the Boot ROM. It's quite basic on these chips: PA9 and PA10 may be used as a UART, if the BootROM determines there is no code in the internal flash.

 

ioport_init() does not change the state of any pins. That function only enables the clock to the IO controllers, so that interrupts and glitch filtering can be used.

 

Your best bet is to assume nothing about the state of the pins after reset, and have the application image set everything up as it requires. That way someone changing your bootloader, or worse, a chip revision from Microchip, won't create a hard-to-find bug in your design.

Josh @ CIHOLAS Inc - We fill the gaps from chips to apps

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

Hi Josh and thanks!

Agreed, that sounds like a good practice.

 

Assuming the case, how is this exactly done? ASF and Atmel are new to me and don't know how to re-set/re-program PIN's if they are set in other states by something else. There's plenty of examples getting into certain PIO_PERIPH_X and also alternate functions, but how to get back to primary functions which is the case here, I haven't seen. Would the snippet I sent in my original post be enough? If you have any snippet to share that would be appreciated.

 

On a related note, I've had a look at the SAM-E70-S70-V70-V71-Family-Data-Sheet-DS60001527D, chapter 8.2 (System I/O Lines) which concerns yet another modality of some of the pins. I can't see any correlation to the ones I have problems with (PD7, PD8) which furthermore on other designs (albeit SAME70J and Q based) works as expected after reboot. But assuming nothing here either, is there any HW modality or pit-falls that you know or have heard of?

 

The list you mention about the pins that ROM boot-loader may affect. Where can I find it?

 

Many thanks!

 

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

To be more specific about non-SW/FW intervention:

 

Can we have inadvertently triggered the Embedded Trace Macro-cell (ETM)? Looking at "Figure 16-1. Debug and Test Block Diagram" this cell has the ability to overtake these pins which may explain the behaviour as these would be outputs.

 

I don't know how/if the cell get's enabled, weather the pin TST (pin 60, which in our case is pulled up) is involved or not.

 

Certain ARM architectures refer to a signal ETMEN but that signal is either obsolete or renamed for Cortex-M7, or enabling/disabling ETM is completely is done via registers (see ARM ETMv4.0 to ETMv4.5 spec )

 

Thanks!

 

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mambrus wrote:

The list you mention about the pins that ROM boot-loader may affect. Where can I find it?

 

Chapter 17, and specifically Table 17-1 of the datasheet.

 

mambrus wrote:

I don't know how/if the cell get's enabled, weather the pin TST (pin 60, which in our case is pulled up) is involved or not.

For normal operation, TST pin should be LOW. Setting TST high and JTAGSEL high enables boundary scan; TST high and JTAGSEL low enables fast flash programming mode.

 

See Chapter 16.7.7 for how ETM is enabled. It's unlikely you did this by accident. But the pull-up on TST may be something to attempt changing.

Josh @ CIHOLAS Inc - We fill the gaps from chips to apps

Last Edited: Mon. Aug 17, 2020 - 01:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I finally got to it to start-up another board. Needed some patching as some HW design errors needed correcting (which is probably where it went wrong on the previous board).

 

It worked on first try without any hick-ups or hesitation. I.e. your original hunch was correct.

 

Thanks for the support!

 

Regards //Michael