Tuesday, May 22nd 2018, 4:27am UTC+2

You are not logged in.

  • Login
  • Register

Date of registration: Dec 21st 2017

Posts: 6

1

Thursday, December 21st 2017, 1:30pm

[SOLVED] J-Link RAMCode problems with Atmel ATSAME70Q21

Hi,

I am using J-Link 6.22d / Ozone 2.54a via a USB J-Link Plus to an Atmel ATSAME70Q21 (Cortex-M7) controller. The debugger connects and identifies the core, but the RAMCode fails to program.

-------------------------------------
J-Link: Device "ATSAME70Q21" selected.
J-Link: Found SW-DP with ID 0x0BD11477
J-Link: Scanning AP map to find all available APs
J-Link: AP[1]: Stopped AP scan as end of AP map has been reached
J-Link: AP[0]: AHB-AP (IDR: 0x04770041)
J-Link: Iterating through AP map to find AHB-AP to use
J-Link: AP[0]: Core found
J-Link: AP[0]: AHB-AP ROM base: 0xE00FD000
J-Link: CPUID register: 0x410FC271. Implementer code: 0x41 (ARM)
J-Link: Found Cortex-M7 r0p1, Little endian.
J-Link: FPUnit: 8 code (BP) slots and 0 literal slots
J-Link: CoreSight components:
J-Link: ROMTbl[0] @ E00FD000
J-Link: ROMTbl[0][0]: E00FE000, CID: B105100D, PID: 000BB4C8 ROM Table
J-Link: ROMTbl[1] @ E00FE000
J-Link: ROMTbl[1][0]: E00FF000, CID: B105100D, PID: 000BB4C7 ROM Table
J-Link: ROMTbl[2] @ E00FF000
J-Link: ROMTbl[2][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
J-Link: ROMTbl[2][1]: E0001000, CID: B105E00D, PID: 000BB002 DWT
J-Link: ROMTbl[2][2]: E0002000, CID: B105E00D, PID: 000BB00E FPB-M7
J-Link: ROMTbl[2][3]: E0000000, CID: B105E00D, PID: 000BB001 ITM
J-Link: ROMTbl[1][1]: E0041000, CID: B105900D, PID: 000BB975 ETM-M7
J-Link: ROMTbl[0][1]: E0040000, CID: B105900D, PID: 000BB9A9 TPIU-M7
J-Link: Cache: Separate I- and D-cache.
J-Link: I-Cache L1: 16 KB, 256 Sets, 32 Bytes/Line, 2-Way
J-Link: D-Cache L1: 16 KB, 128 Sets, 32 Bytes/Line, 4-Way
J-Link: connected to target device
J-Link: Failed to download RAMCode.
Failed to prepare for programming.
Failed to download RAMCode!

--------------------------------------------------------


I guessed that the problem might be that the on-chip watchdog might be restting, as according to the datasheet it does run from startup. So i added the following to the Ozone project.


Target.WriteU32 (400E1854, 0x00008000); // the WDT, bit 15 (1 - disables)
Target.WriteU32 (400E1904, 0x00008000); // the RSWDT, bit 15 (1 - disables)


there was then a pause of several seconds, but RAMCode download still failed.

Now Ozone says..
J-Link: Failed to restore target. RAMCode never stops

and J-Link commander says.


Erasing device (ATSAME70Q21)...
J-Link: Flash download: Total time needed: 0.027s (Prepare: 0.025s, Compare: 0.000s, Erase: 0.001s, Program: 0.000s, Verify: 0.000s, Restore: 0.000s)

****** Error: Failed to restore target. RAMCode never stops

ERROR: Erase returned with error code -5.


So it looks like this is some compatibility problem with the version of J-Link and the ATSAME70Q21 chip.

This post has been edited 2 times, last edit by "matthewjfletcher" (Dec 21st 2017, 1:34pm)


SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 1,048

2

Thursday, December 21st 2017, 3:54pm

Hello,

Thank you for your inquiry.
Such an issue is not known to us.
Are you using an eval board or custom hardware?
We tried to reproduce the issue with a "Smart SAME70 Xplained Ev. Kit" and everything was working as expected.

For reference an Embedded Studio project with a simple hello world example for this target device is attached.
There you will find an Ozone project as well for quick testing with your setup.
Are you able to program the example application with Ozone?
To test it simply open the same70_flashtest.jdebug file with Ozone and start a debug session.

Quoted

I guessed that the problem might be that the on-chip watchdog might be restting, as according to the datasheet it does run from startup. So i added the following to the Ozone project.

This should be taken care off in our flash loader algorithm so you don't have to think about it for programming the flash.

Best regards,
Nino
SEGGER - Nino has attached the following file:
Please read the forum rules before posting: Forum Rules

Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
Should you be entitled to support contact us per e-mail.
The following contact form can be used for this: https://www.segger.com/about-us/contact-us/


Date of registration: Dec 21st 2017

Posts: 6

3

Thursday, December 21st 2017, 4:29pm

Hi,

Yes we did not see the problem on the Atmel dev kit either, but this is custom hardware. When we added the following to the *.jdebug file, that allowed erase and programming to be successful on our custom board.


void TargetReset (void) {
Target.WriteU32(0x400E1854, 0x3FFFAFFF);
}

This disables the onboard Atmel watchdog, i presume the Xplained Kit add a certain pin pulled low to prevent the watchdog running on startup.


There now appears to be a different issue. 'J-Link Failed to read current instruction'.


J-Link: connected to target device
Target.WriteU32 (400E1854, 0x3FFFAFFF);
J-Link: J-Link: Flash download: Bank 0 @ 0x00400000: Skipped. Contents already match
Debug.StepOver();
J-Link: Failed to read current instruction.

Do you know why this would be ?, this is the very first instruction.

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 1,048

4

Friday, December 22nd 2017, 9:44am

Hi,

Quoted

This disables the onboard Atmel watchdog, i presume the Xplained Kit add a certain pin pulled low to prevent the watchdog running on startup.

That would make sense.

Quoted

There now appears to be a different issue. 'J-Link Failed to read current instruction'.


For this case could you provide a J-Link log file?
How to create one is described here: https://wiki.segger.com/Enable_J-Link_log_file

Could you also provide us with an example project where this issue is reproducible?

Best regards,
Nino
Please read the forum rules before posting: Forum Rules

Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
Should you be entitled to support contact us per e-mail.
The following contact form can be used for this: https://www.segger.com/about-us/contact-us/


Date of registration: Dec 21st 2017

Posts: 6

5

Tuesday, January 2nd 2018, 12:42pm

Hi,

Please see attached log file, it still seems the problem is around the ROMCode.


T386C 022:517 JLINK_EndDownload()
-- CPU_ReadMem(4 bytes @ 0xE000ED90)
-- CPU_ReadMem(4 bytes @ 0xE000ED94)
-- --------------------------------------
-- Start of determining dirty areas in flash cache
-- End of determining dirty areas
-- Start of preparing flash programming
-- Calculating RAM usage
-- RAM usage = 5884 Bytes
-- Preserving CPU registers
-- Preparing memory
-- Preparing target
***** Error: Failed to prepare target -- End of preparing flash programming returns 0xFFFFFFFF
(0505ms, 1000ms total)
matthewjfletcher has attached the following file:
  • JLink.zip (5.26 kB - 64 times downloaded - Last download: May 20th 2018, 7:22am)

Date of registration: Dec 21st 2017

Posts: 6

6

Wednesday, January 3rd 2018, 2:39pm

Same problem occurs attempting to erase the internal flash via J-Link Commander.


J-Link>erase ?
Erasing device (ATSAME70Q21)...

****** Error: Failed to prepare target
ERROR: Erase returned with error code -1.

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 1,048

7

Friday, January 5th 2018, 10:31am

Hello,

Thank you for providing the log.
According to the log the initial programming did not succeed. This is most likely due to a not handled watchdog as the RAMCode feeds the watchdogs during runtime.
So one of the watchdogs triggers before the RAMCode can execute.
The SAME70 device series has actually two watchdogs running.
One located at 0x400E1850 (which you correctly disabled) and one at 0x400E1900 called "Reinforced Safety Watchdog Timer".
Both need to be handled/disabled otherwise the RAMCode can't execute.
Could you try to disable both in your Ozone Script and see if the behaviour improves?

Unfortunately I could not find any clues in the documentation about how ATMEL handles the watchdog on their eval board so I suggest to contact ATMEL in that regard how to disable the Watchdogs other than per software.

Should disabling both watchdogs not succeed could you provide us with a reproduction scenario with the eval board?

Best regards,
Nino
Please read the forum rules before posting: Forum Rules

Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
Should you be entitled to support contact us per e-mail.
The following contact form can be used for this: https://www.segger.com/about-us/contact-us/


Date of registration: Dec 21st 2017

Posts: 6

8

Friday, January 5th 2018, 10:54am

Hi,

With the following,.. the problem still occurs.

Target.WriteU32(0x400E1854, 0x3FFFAFFF);
Target.WriteU32(0x400E1904, 0x3FFFAFFF);

I will check with the Xplained Ultra board.

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 1,048

9

Friday, January 5th 2018, 11:10am

Hi,

I just noticed that you do the watchdog register writes in the function TargetReset().
Try using AfterTargetConnect() or AfterTargetReset() instead (depending on if you trigger a download of the application or not).
Make sure to uncomment the function in the script.
Does that solve the issue?

Best regards,
Nino
Please read the forum rules before posting: Forum Rules

Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
Should you be entitled to support contact us per e-mail.
The following contact form can be used for this: https://www.segger.com/about-us/contact-us/


Date of registration: Dec 21st 2017

Posts: 6

10

Friday, January 5th 2018, 3:41pm

Hi,

We had a visit from the Atmel/Microchip support guys, using Atmel Studio as the interface to our J-Link, the key seems to be setting the reset method to 'core', which just resets the debug core, not 'normal' which does a whole CPU reset. This is equivalent to the J-Link 'monitor reset 2' method.

They and we do not understand why the default 'Normal' method does not work, but method 2 'core' does. Using this method we do not have to do memory writes to disable the watchdogs either.

Thank you for all you support.

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 1,048

11

Friday, January 5th 2018, 4:23pm

Hello,

Great to hear that you are up and running again.

Quoted

They and we do not understand why the default 'Normal' method does not work, but method 2 'core' does. Using this method we do not have to do memory writes to disable the watchdogs either.

The difference is that a "normal" reset resets all registers to their default values. For the watchdog it means that it gets reenabled. A Core reset does not do that.
That is why I wrote to put the two Target.Write32 calls into the AfterTargetReset() function. That way you make sure that after each reset the watchdogs stay disabled.

We will consider this case as closed now.

Best regards,
Nino
Please read the forum rules before posting: Forum Rules

Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
Should you be entitled to support contact us per e-mail.
The following contact form can be used for this: https://www.segger.com/about-us/contact-us/