Re: [nuttx] unconditional 32kHz xtal oscillator on SAM34

[Alan Carvalho de Assis <ac...@gmail.com>]

Hi Bernd,

On 1/28/20, Bernd Walter <be...@bwct.de> wrote:
> I have had problens with a new SAM4S based board in that it hang eraly
> during startup, before initializing my 12MHz xtal.
> Also the SWD didn't work anymore until I erased the chip.
> Since the SWD didn't work it was quite obvious that there is some clock
> related issue.
> I've found out that the startup code unconditionally switches to an
> external 32kHz xtal.
> On my board I didn't need one.
> Interestingly I had no such problem on a SAM4E board, but there is
> a small difference between those boards in that the SAM4E has XIN32/XOU3
> pins unconnected and the SAM4S has XIN32 used as GPIO.
> Or maybe the SAM4E just behave differently when trying to init an unhooked
> 32kHz xtal.
> However, after commenting the sam_supcsetup() call my board worked fine.
> I think there should be an option to initialize the 32kHz xtal or not.
>

Please check how other boards are doing it. Normally you have a DEFINE
USE_CLOCK_XYZ inside the boardname/include/board.h.

I faced an issue similar to your on SAMD21, it was defined to use
external crystal, but my board didn't have one. When I enabled the
internal clock the serial console wasn't working correctly. Then
Alexander noticed that it was missing a function to read the NVRAM
calibration data to use with the internal RC clock.

BR,

Alan

Re: [nuttx] unconditional 32kHz xtal oscillator on SAM34

[Bernd Walter <be...@bwct.de>]

On Tue, Jan 28, 2020 at 05:22:08PM +0100, Bernd Walter wrote:
> On Tue, Jan 28, 2020 at 12:40:12PM -0300, Alan Carvalho de Assis wrote:
> > Hi Bernd,
> > 
> > On 1/28/20, Bernd Walter <be...@bwct.de> wrote:
> > > I have had problens with a new SAM4S based board in that it hang eraly
> > > during startup, before initializing my 12MHz xtal.
> > > Also the SWD didn't work anymore until I erased the chip.
> > > Since the SWD didn't work it was quite obvious that there is some clock
> > > related issue.
> > > I've found out that the startup code unconditionally switches to an
> > > external 32kHz xtal.
> > > On my board I didn't need one.
> > > Interestingly I had no such problem on a SAM4E board, but there is
> > > a small difference between those boards in that the SAM4E has XIN32/XOU3
> > > pins unconnected and the SAM4S has XIN32 used as GPIO.
> > > Or maybe the SAM4E just behave differently when trying to init an unhooked
> > > 32kHz xtal.
> > > However, after commenting the sam_supcsetup() call my board worked fine.
> > > I think there should be an option to initialize the 32kHz xtal or not.
> > >
> > 
> > Please check how other boards are doing it. Normally you have a DEFINE
> > USE_CLOCK_XYZ inside the boardname/include/board.h.
> 
> Ok - will do that.
> 
> > I faced an issue similar to your on SAMD21, it was defined to use
> > external crystal, but my board didn't have one. When I enabled the
> > internal clock the serial console wasn't working correctly. Then
> > Alexander noticed that it was missing a function to read the NVRAM
> > calibration data to use with the internal RC clock.
> 
> I have had the same problem with wrong uart clock on a few identic SAMD21
> boards, but results were different.
> My board had been running on internal RC without USB.
> An external 12MHz xtal existed, but I hadn't used it because of lazyness.
> My problem however wasn't the RC, because after switching to the xtal
> the problem still existed.
> In my case it was the DFLL and everything was fine after switching to
> the DPLL.
> The DPLL however is not an option if you want to use the RC and
> still being able to run device USB.

Oh - by the way.
When you use an extarnal xtal on a SAMD21 disable the oscillator power saving
feature (BOARD_DPLL_LPEN/SYSCTRL_DPLLCTRLB_LPEN) while debugging.
The amplitude is insanely low and I couldn't see it swinging on my scope.

-- 
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

Re: [nuttx] unconditional 32kHz xtal oscillator on SAM34

[Bernd Walter <be...@bwct.de>]

On Tue, Jan 28, 2020 at 12:40:12PM -0300, Alan Carvalho de Assis wrote:
> Hi Bernd,
> 
> On 1/28/20, Bernd Walter <be...@bwct.de> wrote:
> > I have had problens with a new SAM4S based board in that it hang eraly
> > during startup, before initializing my 12MHz xtal.
> > Also the SWD didn't work anymore until I erased the chip.
> > Since the SWD didn't work it was quite obvious that there is some clock
> > related issue.
> > I've found out that the startup code unconditionally switches to an
> > external 32kHz xtal.
> > On my board I didn't need one.
> > Interestingly I had no such problem on a SAM4E board, but there is
> > a small difference between those boards in that the SAM4E has XIN32/XOU3
> > pins unconnected and the SAM4S has XIN32 used as GPIO.
> > Or maybe the SAM4E just behave differently when trying to init an unhooked
> > 32kHz xtal.
> > However, after commenting the sam_supcsetup() call my board worked fine.
> > I think there should be an option to initialize the 32kHz xtal or not.
> >
> 
> Please check how other boards are doing it. Normally you have a DEFINE
> USE_CLOCK_XYZ inside the boardname/include/board.h.

Ok - will do that.

> I faced an issue similar to your on SAMD21, it was defined to use
> external crystal, but my board didn't have one. When I enabled the
> internal clock the serial console wasn't working correctly. Then
> Alexander noticed that it was missing a function to read the NVRAM
> calibration data to use with the internal RC clock.

I have had the same problem with wrong uart clock on a few identic SAMD21
boards, but results were different.
My board had been running on internal RC without USB.
An external 12MHz xtal existed, but I hadn't used it because of lazyness.
My problem however wasn't the RC, because after switching to the xtal
the problem still existed.
In my case it was the DFLL and everything was fine after switching to
the DPLL.
The DPLL however is not an option if you want to use the RC and
still being able to run device USB.

-- 
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.