Stuck in Dummy_Handler when initializing I2SC0 on SAME70

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

All,

I've recently created a custom board using the SAME70 based off code I wrote on the SAME70 Xplained. The code on the Xplained works well but when running on the custom board the initialization of the I2SC module cause the code to get trapped by the Dummy_Handler.

A user experienced a similar problem here https://community.atmel.com/forum/strange-program-crashes?skey=Dummy%20handler but their problem seemed to be with their own code instead of an ASF library and their solution did not fix mine. However, I am getting the same register values.

In my board_conf.h file I've oh defined CONF_BOARD_TWI0 for the Xplained header file specifically. I have never used the SRAM module available to the Xplained board so jumping outside of available memory seems unlikely to me.

Any help is much appreciated.

R,
Jacksdh7

This topic has a solution.
Last Edited: Thu. Sep 12, 2019 - 12:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The peripheral block needs to be enabled and the clock needs to be enabled before accessing the peripheral. If not, you get a bus fault that sends you to the dummy handler. Other problems might be an unaligned access or the pointer is invalid.
You can check to see if the peripheral is accessible in the debugger by reading the peripheral’s registers. Its been some time since i’ve used studio7 so i can’t remember the specifics. Nevertheless, the debugger will give some indication if there is a problem. You can also check the various peripheral registers used to enable the peripheral in question.
If it is a pointer problem and you know where in the code it occurs, set a breakpoint just before the problem and go to the asm mode in the debugger and single step each instruction. The trap will happen on a load or store instruction. Look at the contents of the cpu register used for the pointer. Check to see this is a valid address of the peripheral. If not valid, work back through your code to see where it goes wrong. Typical issues might be wrong base address or doing a word access on a non word aligned address.

Just had another look at your question - there’s I2S and I2C - sure you’re not confusing them?

Last Edited: Sun. Sep 1, 2019 - 10:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman,

 

Thanks for the response, I am indeed talking about I2S. I'm defining CONF_BOARD_TWIHS0 for I2C because it is already setup as part of the Xplained header file and I don't have to write the code myself. The setup for I2C seems to work on my custom board without hitting the Dummy_Handler. I manually wrote the code for I2S because it is not actually enabled on the Xplained board and I had to make some small hardware mods to get to the pins. This I2S code works for the Xplained board but hits the Dummy_Handler on my custom board which seems strange to me.

 

By enabling the peripheral block do you mean setting the modes for the pins? I believe I am doing that correctly with the "ioport_set_pin_mode" function. As for the clock, I am calling the "i2s_enable_clocks" function after the problem occurs on "i2s_init" but I did try running it by placing it before but it caused the same issue. Also, running the "i2s_enable_clocks" after the "i2s_init" function works on the Xplained board and is also the order in which it was written in the unit test example provided in the ASF API.

 

I'm wondering if I missed an important pin that needs to be connected so that I2S will work properly but nothing is jumping out to me at the moment. I will post the contents of the registers from both the Xplained and my board as soon as I am able. If you have any additional suggestions from the new information I've given please let me know.

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

There’s usually a power control or system control register where you can enable/disable peripherals to save power. Through the debugger you should be able to manually enable the power and clocks and the debugger should be able to view the i2s peripheral regs. If it gives an error whilst doing this, then that suggests the peripheral is not correctly enabled. Once you’ve confirmed the peripheral is actually enabled,then look at pin config.

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

Ok so it looks like the issue if that the address of the I2SC0 peripheral doesn't seemed to be populated with anything. The address define in the header file for my specific chip, the SAME70q21b, is 0x4008C000U. When I run the program using the Xplained board the registers of the I2SC0 are populated:

	I2SC_CR	        0	volatile uint32_t
	I2SC_MR	        0	volatile uint32_t
	I2SC_SR	        0	const volatile uint32_t
	I2SC_SCR	0	volatile uint32_t
	I2SC_SSR	0	volatile uint32_t
	I2SC_IER	0	volatile uint32_t
	I2SC_IDR	0	volatile uint32_t
	I2SC_IMR	0	const volatile uint32_t
	I2SC_RHR	0	const volatile uint32_t
	I2SC_THR	0	volatile uint32_t
	I2SC_VERSION	257	const volatile uint32_t

However, when I run it on my custom board the values are blank as if there isn't any memory there at all. It looks like this: 

        I2SC_CR		       volatile uint32_t
        I2SC_MR		       volatile uint32_t
	I2SC_SR		       const volatile uint32_t
	I2SC_SCR	       volatile uint32_t
	I2SC_SSR               volatile uint32_t
	I2SC_IER		volatile uint32_t
	I2SC_IDR		volatile uint32_t
	I2SC_IMR		const volatile uint32_t
	I2SC_RHR		const volatile uint32_t
	I2SC_THR		volatile uint32_t
	I2SC_VERSION		const volatile uint32_t

Seeing as I'm using the exact same chip as is on the Xplained I'm not sure how I wouldn't be able to read any memory from the peripheral address. Could it be because I need to "enable" those addresses?

 

Edit:

 

Looked at the memory itself in the debugger. The Xplained shows normal values while my custom board shows ?? starting exactly at the 0x4008C000 address.

Last Edited: Sun. Sep 8, 2019 - 08:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to clarify, it seems the cause of the problem is because I cannot read the memory where I would expect to find the I2S peripheral. Any ideas as to why this would be the case?

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

New update, I found how the Debug->Windows->IO tool and tried to toggle the I2S bits directly from there to turn on the clock, enable transmit and receive, etc but I cannot toggle any of the bits.

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

Have you enabled the peripheral? I've not used this chip recently, so I can't recall where to steer you

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

I took a look in the document and it says:

The I2SC features a receiver, a transmitter and a clock generator for Master and Controller modes.
Receiver and transmitter share the same serial clock and word select.

Before enabling the I2SC, the selected configuration must be written to the I2SC Mode Register
(I2SC_MR) and to the Peripheral Clock Configuration Register (CCFG_PCCR) described in the section
“Bus Matrix (MATRIX)”.

Taking a look at what the "i2s_init" function does it very much look like it is doing everything correctly in enabling the peripheral. I am able to manually change the bits for other peripherals just fine but when I try to do it with I2SC it looks at tho neither the debugger or I can read/write from that memory space.

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

I figured it out. Unfortunately, I was sent a revision A chip by mistake instead of the required revision B. Revision A has I2SC disabled completely and that is why I couldn't even read the memory from the address.

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

Well! That will mess up your day.