Welcome to AT91SAM Community Discussions

Hi Forum,

I have a fairly minimal custom board with SAMA5D36.

I'm using the IAR IDE via JTAG to test the new board (as bare metal) and get things running (operating from internal SRAM).

I'm using the Debug serial port to monitor activity; at power up I get "RomBOOT", then I send "#" to allow the JTAG to work and then I can run the debugger on IAR.

I have the tested some basic functions such as controlling PIO's - these work OK. I can step through code and view registers and memory etc, and run code that flashes LED's.

The strange behavior includes:

1) I cannot send data over the Debug serial port with "printf". I get chars coming into my terminal, but they are always 0x00. While I can change the baud rate via the usart register (using JTAG / IAR), if I try to change the TX holding register value, it always reverts to 0x000. The same behavior occurs on USART3. I know the Debug serial port can work, because it provides the data string "RomBOOT" at startup when the first level bootmonitor runs, and I can input "V#" and get the RomBOOT version (2.1).

2) I implemented an ISR using the PIT. If I poll for the timeout it clearly works, but does not generate an interrupt. The same code works OK on the ATSAMA5D3 Xplained board.

I have used the ATSAMA5D3 Xplained board a lot and do not see this behavior. I'm thinking perhaps I have missed something and operating JTAG after the RomBOOT might be leaving the ATSAMA5D3 in a strange state that needs to be changed.

I'm using a ATSAMA536 engineering sample from ATMEL - I'm pretty sure these should work just like a chip brought through a place like Digikey...?

Anyway, it's pretty strange...

Comments and suggestions or similar experiences are welcome.

Thanks,

Hi MrHat,

To answer some of the question, it appears that the peripheral clock is not getting set to the correct rate after the JTAG resets the SoC. This results in the serial baud rates being wrong (by a factor of 3), resulting in all 0x00 in the terminal.

Also, the USART TX holding register is write only, so will always read 0x000 (DOH !!!)

Some other issues have come up in this very minimal board build that I did not know, but is buried deep in the documentation ... so for those designing minimal boards for SAMA5D ...

1) For the USB to work, and external crystal or TCXO oscillator is required. USB will not work with the internal RC clock.

2) For the SAM-BA application to work properly (load applets etc), external memory is required. My software designs are bare-metal and small, so could run from internal sram; to keep the PCB small in simple I did not add external memory.

In addition to the previous problems with using the SAMA5D3 there is discrepancy about the function of the BMS pin and bit.
The data sheet implies (section 11.1) if BMS pin == BMS bit == 0, then the EBI connected NOR flash will be used for BOOT. If BMS pin == BMS bit == 1 then the standard boot (with BA-Monitor) will be used. However in section 56.4, if the BMS bit == 0, standard boot (ROM) will be used, if BMS bit == 1 then EBI NOR flash will be used. The AN-9547_SAMA5D3_D4_Boot.pdf also supports this version. It appears there has been confusion over this in the document history, but I have found that holding the BMS pin high with a 1k resistor disables the ROM monitor from running. With the resistor removed the BMS pin is held low by an internal resistor.

In summary: Tying the BMS pin high on a PCB design will disable access to the ROM monitor.....