How to run Programm on XMC1100 without DAVE

[#1]

Hello everybody,
I have developed a programm including USIC, UCC40, ADC to control hydraulic machines on the XMC1100 for Arduino development board. All works fine under DAVE. Now I want to download the program so that the board works stand alone.
Can somebody give me some advice about what to set in Dave to download.

thanks a lot.

[#2]

Hi,

Set your project in DAVE to "Release" and download like how you did with debug.
With the project set to release, debug feature is no longer available.
So, you just run "debug" and after download you can just stop it.
Then the code will be programmed into the device/board.

[#3]

Thanks for your reply. I am using DAVE 3, but I could not find where to set DAVE to "Release". Please advise.

[Travis]

To set your project to release state.

Right click on DAVE3 project >> Build configuration >>set active >> release

[#5]

Thanks, it works, now

[#6]

Hi,

I was just reading Jackson's reply. The behaviour we see, differs. With the project in Release mode, if I use the beetle icon, to download our software, and then the |> button to run the software, it runs fine. If I hit the stop button, the software stops, though.

Perhaps Jackson meant instead, close the Debug window. If I do that, good news, our software carries on running. But, if I close DAVE, our software stops.

Alternatively, if I keep DAVE open, but powercycle our board, then the software doesn't start up. And in DAVE, I get the usual dialogue each time I try beetle, of 'Launching Project Debug' has encountered a problem. Debug session 'Project Debug' already started. Terminate the first one before restarting'. The Details button, says the same.

But there isn't any first one to terminate - I had closed the Debug window. So as usual, I have to close and reopen DAVE, to 'rebeetle' the software. Actually, is the dialogue normal, do other folks see this? Or is something 'up', with our project, and/or, DAVE configuration?

Our project 'started life' as just the DAVE example project for Modbus RTU / ASCII. So its configured whatever way that is.

All the above is also true, if I do the usual thing, of deleting the debug configuration, and adding a new one.

I kind of wondered, if this 'single run' behaviour, had anything to do with the '-singlerun' option, in the debug configuration 'Other options' box. But temporarily removing -singlerun, made no difference.

All of the above is also true, with the project in Debug mode.

So, how do I break our software 'umbilical connection', to DAVE ?

Infact, there doesn't actually seem to be any difference between Release mode and Debug mode. I can debug in both. Well, set breakpoints, and watch variables, which is all I do. And performance of the code seems the same, for both.

Is there something set wrong, that makes Release mode, act as Debug mode, perhaps ?

Best regards,

David

[User12775]

Use a flash tool, for example memtool or Infineon Flasher, and flash the .bin or .hex into your XMC chip.

[#8]

Hi aurixuser,


Many thanks for your reply. I tried straightaway, then got diverted off. But back on the topic again now.


Yes, I've tried the Infineon XMC Flasher, with same results. I can see that the Flasher just launches J-Flash, with the 4 blue progress bars across the screen. Flasher says everything has programmed and verified OK. With Flasher, I've also tried an Erase before programming, and Verify command after, and all reports OK. I'm using the latest J-Flash, 6.16f, and Flasher even prompted to update the J-Flash firmware, which I OK'd. I'm also using the latest Java JRE runtime, jre-8u131-windows-x64. I updated to the latest, per the release notes for Flasher.

I've also tried J-Flash Lite, directly.

And of course, as launched by DAVE 4.3.2.


I've also tried the latest Infineon Memtool 4 (4.07.03 Build 4708 Frontend version 1.19.3 Server version 1.33.5), but got stuck at the dialogue titled 'Create or use default'. Apologies, I would attach, but I don't think I have enough Forum points yet, to be allowed to..

So, under XMC4300, I chose 'Use a default target configuration', then XMC4300, which is what we're using, then a choice of:

Starter Kits (Bootstrap Loader), and Infineon XMC4300 Relax Kit with XMC4300-F100x256 (BSL/ASC), and
Starter Kits (Bootstrap Loader), and Infineon XMC4300 Relax Kit with XMC4300-F100x256 (DAS)

I don't know what BSL/ASC or DAS are, so was stuck here. I will try and google.

Anyway, neither worked. They both reported a series of errors, saying 'Can't establish Connection to Target':

Message from component 'IMTMemtool' :
Can't connect to Target

Message from component 'CortexJtagIntf' :
Can't connect target !

Message from component 'CortexJtagIntf' :
Failed to connect target device !


The Change.. Target Interface Setup didn't give me any ungreyed options that matched the XMC Link SEGGER J-Link based probe we are using.


I also tried, the 'Create a new target configuration step by step' option. But that failed, just after it offered to add something named a 'UDE Add-In'.
It failed with these errors:

Message from component 'IMTMemtool' :
Component initialisation failed !

Message from component 'IMTMemtool' :
No core available for FLASH programming !


As mentioned, our project started life, as the Infineon example poject, for Modbus RTU.

In DAVE, I have Build Configurations > Set Active > Release, selected presently. As such, the project root, says 'Project [ Active - Release ]'. In Properties > Run/Debug Settings, I see a single entry, with the name 'Project Release'. If I click Edit.., to view its settings, I see on the Startup tab, it has 'Initial Reset and Halt'. Is that right, and intended? Is that the problem?

If I delete the 'Project Release' entry, and create a New one, or click the 'Restore Default' button, the same is true. So I imagine DAVE thinks the mentioned settings, are what is appropriate by default, for a release build.


Under Runtime Options, 'RAM application (reload after each reset/restart)', is unchecked. That pretty much describes, the behaviour we see. I wonder, is there perhaps a bug in DAVE, that has that checkbox, reversed ?


When I build our project, with Build Configurations > Set Active > Release selected, it comes out as 62896 bytes. With Build Configurations > Set Active > Debug selected, to comes out as 92032 bytes. Full optimisation (-O3), is selected presently for both.

So I'm fairly sure the release build, omits debug code.


In DAVE, with Build Configurations > Set Active > Release selected, if I click the DAVE toolbar Run button (green circled white triangle), the application downloads to our board, with the usual 4 blue progress bars, although they complete in a fraction of a second. Then, the following is reported:

SEGGER J-Link GDB Server V6.12j - Terminal output channel
Connection closed by the GDB Server.

Do you know, is that good? bad? normal?

The application seems to run, which I presume, means good. And I can close DAVE, and it carries on running, which is an improvement on what I was seeing originally.

However, if I powercycle our board, then our application software doesn't start. Completely dead, no startup LED transitions. So I don't think it it crashing. It is just, not starting.


Below, BTW, is what we see on-screen, when I click the DAVE Debug button (Beetle). Can you spot anything awry, in the following, maybe?

I am wondering, for example, whether an 0x0C000000 start, for our application, looks OK? Correct me if incorrect, but I heard that 0x0C000000 is non-cached FLASH, whereas 0x0800000 is cached FLASH. Perhaps one works, and the other doesn't, for application startup. But we would have inherited that, from the DAVE example project for Modbus RTU. And I don't know how one would go about changing, that.


SEGGER J-Link GDB Server V6.12j Command Line Version

JLinkARM.dll V6.12j (DLL compiled Feb 15 2017 18:01:10)

-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: on
Init regs on start: on
Silent mode: off
Single run mode: on
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: XMC4300-F100x256
Target interface: SWD
Target interface speed: 1000kHz
Target endian: little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link Lite-XMC4200 Rev.1 compiled Apr 5 2017 11:59:07
Hardware: V1.00
S/N: 599000558
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0x2000FF3C)
Read 2 bytes @ address 0x00000000 (Data = 0xFF3C)
Target interface speed set to 1000 kHz
Resetting target
Halting target CPU...
...Target halted (PC = 0x08000200)
R0 = E000ED08, R1 = 00000263, R2 = 02000080, R3 = C8000201
R4 = 00000536, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 0C000004, R10= 00000000, R11= 00000000
R12= 00000000, R13= 1FFF0800, MSP= 1FFF0800, PSP= 00000000
R14(LR) = 000000ED, R15(PC) = 08000200
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Read 4 bytes @ address 0x08000200 (Data = 0xD074F8DF)
Read 2 bytes @ address 0x08000200 (Data = 0xF8DF)
Select auto target interface speed (1875 kHz)
Flash breakpoints enabled
Read 4 bytes @ address 0x08000200 (Data = 0xD074F8DF)
Downloading 668 bytes @ address 0x0C000000 - Verified OK
Downloading 4096 bytes @ address 0x0C020000 - Verified OK
Downloading 4096 bytes @ address 0x0C021000 - Verified OK
Downloading 4096 bytes @ address 0x0C022000 - Verified OK
Downloading 4096 bytes @ address 0x0C023000 - Verified OK
Downloading 4096 bytes @ address 0x0C024000 - Verified OK
Downloading 4096 bytes @ address 0x0C025000 - Verified OK
Downloading 4096 bytes @ address 0x0C026000 - Verified OK
Downloading 4096 bytes @ address 0x0C027000 - Verified OK
Downloading 4096 bytes @ address 0x0C028000 - Verified OK
Downloading 4096 bytes @ address 0x0C029000 - Verified OK
Downloading 4096 bytes @ address 0x0C02A000 - Verified OK
Downloading 4096 bytes @ address 0x0C02B000 - Verified OK
Downloading 4096 bytes @ address 0x0C02C000 - Verified OK
Downloading 4096 bytes @ address 0x0C02D000 - Verified OK
Downloading 4096 bytes @ address 0x0C02E000 - Verified OK
Downloading 4096 bytes @ address 0x0C02F000 - Verified OK
Downloading 4096 bytes @ address 0x0C030000 - Verified OK
Downloading 4096 bytes @ address 0x0C031000 - Verified OK
Downloading 4096 bytes @ address 0x0C032000 - Verified OK
Downloading 4096 bytes @ address 0x0C033000 - Verified OK
Downloading 4096 bytes @ address 0x0C034000 - Verified OK
Downloading 4096 bytes @ address 0x0C035000 - Verified OK
Downloading 1252 bytes @ address 0x0C036000 - Verified OK
Downloading 3696 bytes @ address 0x0C0364E4 - Verified OK
Read 4 bytes @ address 0x08000200 (Data = 0xD074F8DF)
Resetting target
Halting target CPU...
...Target halted (PC = 0x08000200)
Read 2 bytes @ address 0x08031CFC (Data = 0xE92D)
R0 = E000ED08, R1 = 00000263, R2 = 02000080, R3 = C8000201
R4 = 00000536, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 0C000004, R10= 00000000, R11= 00000000
R12= 00000000, R13= 1FFF0800, MSP= 1FFF0800, PSP= 00000000
R14(LR) = 000000ED, R15(PC) = 08000200
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Read 4 bytes @ address 0x08000200 (Data = 0xD074F8DF)
Setting breakpoint @ address 0x08031CFC, Size = 2, BPHandle = 0x0001
Starting target CPU...
...Breakpoint reached @ address 0x08031CFC
Reading all registers
Read 4 bytes @ address 0x08031CFC (Data = 0x4FF0E92D)
Removing breakpoint @ address 0x08031CFC, Size = 2
Reading 64 bytes @ address 0x08031CC0
Reading 64 bytes @ address 0x08031D00
Reading 64 bytes @ address 0x08031D40
Reading 64 bytes @ address 0x08031D80
Read 2 bytes @ address 0x1FFF07D6 (Data = 0x0101)
Read 2 bytes @ address 0x1FFF07D6 (Data = 0x0101)


So, lots of things it could be. I can make a start on trying all the permutations. But it would be very much a blind investigation. It would be good to know how things are 'supposed' to be..

..I've worked with quite a few CPUs, from a few different vendors, and I must admit, I am struggling to understand why this most basic of operations, a Release build, doesn't just, well, work..!


Appreciating any insights aurixuser, or anyone, might be able to offer..


Best regards,

David

[User12775]

If you would like some simple flash & run operation, let's me show you a few.

1. Jlink Lite
Since the jlink on the XMC1x bootkits and XMC4x relaxkits is a special version. You could not use the full-version Jlink-ARM, instead use the Jlink-Lite, which is the JFlasher's approach.

First extract the hex from your .elf file.
Right click your .elf file, click the Properties

At this point you should have the generated hex file.

Lauch the J-Flash Lite tool, assuming you have downloaded and installed it.

Choose the correct chip type, interface and speed.

Select the correct hex file aforementioned, and program the chip, wait... and job Done!

[User12775]

2. XMC Flasher
Open the XMCFlasher.jar, assuming you have downloaded and installed it.

Choose the chip type.

If the BMI and interface are configured correctly , the board will be automatically connected.

Select the .hex file.
Program and job Done!

[User12775]

Memtool is too complex and confusing. I rarely use it for XMC flashing job. But memtool have many features which are not included in Flasher.

Here I ignore memtool. Hope you could complete your flashing job with the replies above.

[#12]

Hi aurixuser,

Many thanks, for the informative posts. Yes, I had tried J-Flash Lite and XMC Flasher. In both cases, they report successful flashing. But our application doesn't start running. Is it *supposed* to, straight after flashing? It also doesn't start running, after powercycle of our board.

So it's a startup problem, rather than a flashing problem. I'm sure there's some simple checkbox or something, somewhere, that needs ticking, that everyone knows about, but I can't find information about..

In DAVE, with active project Release, when I click the 'Run project' icon (white arrowhead on green circle), DAVE flashes the application, showing the same progress dialogue as J-Flash Lite, with the 4 blue progress bars, and when done, reports as follows (is this normal ?), and then runs our application, fine. And indeed, I can exit DAVE, and the application carries on running. But the application won't *re-run*, after powercycle of our board.

SEGGER J-Link GDB Server V6.16f - Terminal output channel
Connection closed by the GDB server.

I didn't quite understand your reference, to *right-clicking* our .elf file. But, I can confirm, that our Output file format, is set to 'ihex'. Always has been. We inherited that setting, from the DAVE example projects. And indeed, when I build, I see appearing in the Release folder, an .elf and a .hex file, both having the date and time of the build..

The settings I have, in DAVE Run configurations.., are the default you get, when you right-click on 'GDB SEGGER J-Link Debugging', and choose New..

Best regards,

David

[User12775]

If you need, please use my hex file. Flash it into your board.


On my board, P0.7 will blink at 1Hz. I have a LED connected to P0.7 .

Yes, there are many ways to solve your confusion.

For example, you could debug your program step by step.

[#14]

Hi aurixuser,

Many thanks for the hex file. I don't suppose, I might trouble you for a version that toggles instead, P1.10, or P1.11 ?

Our design has LEDs attached to both of those. Unfortunately, our one fully-working PCB, is mounted in a metal box,
which is where the boss wants to keep it. Otherwise, I could remove, and use your hex as-is, and monitor P0.7 with a scope.

As to debugging, if I powercycle our board, the debugger loses connection. So unfortunately, I can't see what is causing our
software not to start, after powercycle.

I'm starting to think, it might be some issue with our board hardware design..

Best regards,

David

[User12775]

No problem. Now is the .hex file for toggling both P0.10 and P0.11 at the frequency of 1Hz.

I have not tested it. Because I have no LEDs attached to these two pins and the Oscilloscope at my hand.

Whether it works, please give me a simple reply.

[User12775]

Sorry I made mistake.

But both my two boards have not P1.10 and P1.11 available.

Could you tell me your chip's full type and package?

[#17]

Hi aurixuser,

It's a XMC4300-F100x256 100 LQFP

Best regards,

David

[User12775]

David King, get it!



This is an APP generated project. Because I have not the XMC4300, you need to test for yourself.

The main.c is the only file I edited beside the GUI design work.

/*
 * main.c
 *
 *  Created on: 2017 Jul 20 02:37:31
 *  Author: Administrator
 */




#include                  //Declarations from DAVE Code Generation (includes SFR declaration)

void LED_Toggle_EverySec(void)
{
	DIGITAL_IO_ToggleOutput(&DIGITAL_IO_0);
	DIGITAL_IO_ToggleOutput(&DIGITAL_IO_1);
}

/**

 * @brief main() - Application entry point
 *
 * Details of function

 * This routine is the application entry point. It is invoked by the device startup code. It is responsible for
 * invoking the APP initialization dispatcher routine - DAVE_Init() and hosting the place-holder for user application
 * code.
 */

int main(void)
{
  DAVE_STATUS_t status;

  status = DAVE_Init();           /* Initialization of DAVE APPs  */

  if(status != DAVE_STATUS_SUCCESS)
  {
    /* Placeholder for error handler code. The while loop below can be replaced with an user error handler. */
    XMC_DEBUG("DAVE APPs initialization failed\n");

    while(1U)
    {

    }
  }

  // Create Software timer
#define ONESEC	1000
  uint32_t TimerId = (uint32_t)SYSTIMER_CreateTimer(SYSTIMER_TICK_PERIOD_US,
		  SYSTIMER_MODE_PERIODIC,
		  (void*)LED_Toggle_EverySec,NULL);
  /* Placeholder for user application code. The while loop below can be replaced with user application code. */
  while(1U)
  {

  }
}

[#19]

Hi aurixuser,

I finally got back to looking at this. Thank you very much, for your assistance. I think half the battle, is knowing just what is 'normal', and what is not. Perhaps, you can let me know if anything below, is not 'normal'. I've read around, but can't find it documented anywhere..

Unfortunately the hex file as-is, didn't toggle my P1.10 or P1.11 LEDs, oh well.

So I tried creating a new DAVE project, selecting our XMC4300-F100x256 CPU, and building the default main.c that DAVE provides. That built fine, and I could debug download and run within DAVE.

Next, I tried the main.c that you provide above. Unfortunately, that wouldn't build. But with a few modifications, I ended up with the below, and that flashes our two LEDs. A bit faster than every second, but fine for the purpose of checking our boot issue..

I've no idea why I need the two xmc includes, as I don't in our usual application. But they made my XMC_GPIO_SetMode and XMC_GPIO_ToggleOutput, work. And I've no idea why the software timer code didn't work. But that's by-the-by. The main thing is, the LEDs toggle. After the code, my findings..


/*
* main.c
*
* Created on: 2017 Jul 20 02:37:31
* Author: Administrator
*/




#include //Declarations from DAVE Code Generation (includes SFR declaration)
#include "xmc_gpio.h"
#include "xmc4_gpio_map.h"

void LED_Toggle_EverySec(void)
{
XMC_GPIO_ToggleOutput(P1_10);
XMC_GPIO_ToggleOutput(P1_11);
}

/**

* @brief main() - Application entry point
*
* Details of function

* This routine is the application entry point. It is invoked by the device startup code. It is responsible for
* invoking the APP initialization dispatcher routine - DAVE_Init() and hosting the place-holder for user application
* code.
*/

int main(void)
{
DAVE_STATUS_t status;

status = DAVE_Init(); /* Initialization of DAVE APPs */

if(status != DAVE_STATUS_SUCCESS)
{
/* Placeholder for error handler code. The while loop below can be replaced with an user error handler. */
XMC_DEBUG("DAVE APPs initialization failed\n");

while(1U)
{

}
}

XMC_GPIO_SetMode(P1_10, XMC_GPIO_MODE_OUTPUT_PUSH_PULL);
XMC_GPIO_SetMode(P1_11, XMC_GPIO_MODE_OUTPUT_PUSH_PULL);

// Create Software timer
//#define ONESEC 1000
// uint32_t TimerId = (uint32_t)SYSTIMER_CreateTimer(SYSTIMER_TICK_PERIOD_US,
// SYSTIMER_MODE_PERIODIC,
// (void*)LED_Toggle_EverySec,NULL);
/* Placeholder for user application code. The while loop below can be replaced with user application code. */
while(1U)
{
uint32_t x;

x=0;
do x++;
while (x!=999999);

LED_Toggle_EverySec();
}
}


..In DAVE, after downloading, when I clicked the DAVE play button, the LEDs starting toggling. If I then closed the DAVE Debug window, they carried on toggling. Result! If I then closed DAVE, they stopped toggling (normal?). Likewise, if I closed DAVE, without first closing the DAVE Debug window, they stopped toggling (normal?).

Then, I tried powercycling our board (it's a specific design, not the Infineon Relax XMC4300 evaluation board). I kept power off for a good 15s. And did so for every powercycle test. After power on, the LEDs *didn't* start toggling (normal? maybe yes, maybe no..). This is with the board still connected to my PC, via the 'Infineon XMC Link, Isolated Debug Probe, based on SEGGER J-Link Technology', that we are using. Actually, here's a link, it's one of these: http://uk.rs-online.com/web/p/processor-microcontroller-development-kits/1113727/

Then, I tried powercycling our board, with the PC disconnected from the XMC Link, via the USB cable, but with XMC Link still connected to our board, via the 10-pin JTAG header. Same, the LEDs didn't start toggling (normal?). Lastly, I tried with XMC Link disconnected from our board, and now, after board powercycle, the LEDs started flashing. Result!

Now, with board power off, I tried reconnecting everything. And on board power up, the LEDs started flashing, unlike when I first tried that, as above! I then again tried, with XMC Link disconnected just from PC, and with XMC Link disconnected from board, and same results as above.

I repeated this a few times, and the behaviour is repeatable.

Then, I tried all of the above again, but with one difference: I *didn't* close the DAVE Debug window, before I powercycled. On powercycle, the DAVE Console window goes berserk, displaying a rapidly scrolling list of errors saying it cannot read various registers while CPU is running (er, the CPU is not running, the power is off!). But, the good news is, the LEDs start toggling, at power on. Is this how folks set their boards 'adrift' from DAVE normally..? All those scrolling errors, when I saw them before, made me think, this can't be the right way to do it.. The rest of the results, were as before.

I also tried all of the above, with a second 'XMC Link' unit, with the same results.

Then, I moved to our application, to see how that compared.

Hmm, some differences, I don't know why. In some cases for the better, but in one important case, for the worst! All of the following, repeatable:

If I close the Debug window, our application carries on running, and it also carries on running if I then close DAVE, unlike with the LED flasher app. Also, if I just close DAVE, without first closing the Debug window, our application carries on running, unlike with the flasher app.

If I then powercycled our board, with everything still connected, our application didn't start, as for the flasher app. Same, with the PC disconnected from the XMC Link. But same also, with the XMC Link disconnected from our board. And therein, is our problem. And I'm not sure, how I can 'debug' that problem, as it only occurs with our application cut loose, from XMC Link, unlike for the flasher app.

I'm guessing, our application is perhaps ending up where it says 'Do nothing', below. In other words, the problem perhaps, is not with our application, per-se, but with one or more of the DAVE APPs, encountering an initialisation failure. And *only* when our application is powering up, not when running from DAVE..

If that's where the problem is, *many* thanks, for helping me in reaching that realisation. I think next, I'm going to try adding some LED flashing, to where it says 'Do nothing', to see if my theory, is correct. And if so, then I'll try programming some kind of flashing sequence or count, morse code style, to tell me which DAVE APP or APPs, are failing, and in due course, how..


// DAVE APP initialise

status = DAVE_Init( ); // Initialise

if ( status == DAVE_STATUS_FAILURE )
{
// Placeholder for error handler code. The while loop below can be
// replaced with a user error handler.
XMC_DEBUG("DAVE APPs initialization failed\n");
while ( true )
{
// Do nothing
}
}


But, is there anyway I can shortcut this activity? I'm thinking, can I somehow 'instigate' a power-up of our board, but then be able to connect-up with the DAVE debugger, to be able to easily see which APP or APPs are failing, and why ?

For information, our application uses the following APPs, one or more of each:

CAN_NODE, CLOCK_XMC4, CPU_CTRL_XMC4, E_EEPROM_XMC4, ECAT_SSC, EVENT_DETECTOR, EVENT_GENERATOR, ETH_LWIP, GLOBAL_CAN, GLOBAL_CCU4, GLOBAL_SCU_XMC4, INTERRUPT, SEGGER_RTT, SYSTIMER, TIMER, UART, WATCHDOG.

In case you're wondering, SEGGER_RTT is third-party, referenced by ETH_LWIP, if statistics report is enabled. But we've had this boot problem, from day one, well before we started using SEGGER_RTT.

Oh, and one last thing: We get no such boot problem, when we run our application on the Infineon Relax XMC4300 Evaluation board, or the Infineon Relax XMC4800 Evaluation board (we've got a build of our application, for both of those, for comparative checks). The source code, and all of the APP configurations, are identical for all 3. The only differences, are some conditional compilation, to accommodate the fact that the Relax XMC4300 lacks Ethernet, and that both Relaxes lack 2 additional UARTs, that our board has. But any conditional coding is well after DAVE APP initialise completes. Infact, for the Relax builds, we even have the additional UART APPs present, but configure the transmit and receive pins as 'Not selected', just to keep everything as similar as possible for the 3 builds..

..a key difference with the Relax boards, of course, is that something similar to XMC Link, is integrated onto the Relax boards. So for the Relax boards, you cannot actually disconnect the XMC Link bit, from the rest of the board. You can only disconnect the XMC Link, from the PC, via USB cable. Which it makes it all the more odd that our application, running on the Relax boards, boots fine. Because with our board, with our application, or the flasher app, it won't boot, with just the XMC Link connected..

Best regards,

David

[#20]

Hi aurixiser, and anyone else reading along 🙂

SOLVED !

Well, a solution, at least.
The jury is still out, on the cause ..

First, I tried adding some LED flashing, to the 'Do nothing' loop below, and power-cycling our board, *without* XMC Link adaptor attached.
The code didn't reach the 'Do nothing'.

// DAVE APP initialise

status = DAVE_Init( ); // Initialise

if ( status == DAVE_STATUS_FAILURE )
{
// Placeholder for error handler code. The while loop below can be
// replaced with a user error handler.
XMC_DEBUG("DAVE APPs initialization failed\n");
while ( true )
{
// Do nothing
}
}

Next, I tried moving the LED flashing, up to immediately *before* the DAVE_Init( ) call, and power-cycled. The code reached that flashing !
So, our board is actually booting !! It was just giving every appearance, of not. After 4 months, our software is finally running free of DAVE !! (No offence, DAVE)..

Now, some investigating. And I eventually discovered, using some LED flashing, that the place within DAVE_Init( ), where the code was stopping, was within the while loop below,
in file xmc_eth_mac.h. Remember, that I cannot use the debugger to investigate, as the problem occurs only on board power-up. Not reset, while running.. (unless anyone can tell
me how to debug, from power-up).


/**
* @param eth_mac A constant pointer to XMC_ETH_MAC_t, pointing to the ETH MAC base address
* @return None
*
* \parDescription:

* Reset the ETH MAC peripheral

*
* \par
* The function resets the ETH MAC peripheral. It blocks until reset.
*/
__STATIC_INLINE void XMC_ETH_MAC_Reset(XMC_ETH_MAC_t *const eth_mac)
{
eth_mac->regs->BUS_MODE |= (uint32_t)ETH_BUS_MODE_SWR_Msk;
while ((eth_mac->regs->BUS_MODE & (uint32_t)ETH_BUS_MODE_SWR_Msk) != 0U)
{
}
}


So, what this DAVE code is doing, is setting SWR Software Reset bit 0, of register ETH0_BUS_MODE. And then, looping indefinitely,
until the bit returns to zero. Or in our case, it never does (I waited an hour). Here's what the XMC4300 Reference Manual says, on the SWR bit:

'When this bit is set, the MAC DMA Controller resets the logic and all internal registers of the MAC. It is cleared automatically after the reset operation has completed in all of the DWC_ETH clock domains. Before reprogramming any register of the DWC_ETH, you should read a zero (0) value in this bit. Note: * The reset operation is completed only when all resets in all active clock domains are de-asserted. Therefore, it is essential that all the PHY inputs clocks (applicable for the selected PHY interface) are present for the software reset completion.'

My theory then, is that for whatever reason, DAVE code set of the SWR bit, is infact actually not actually resetting our Ethernet PHY. And hence, the while loop, is looping indefinitely, waiting for SWR bit return to zero, which is never going to come.

About the LED flashing, before DAVE_Init( ), purely by chance, I tried increasing the duration of the flashing, to observe it, for a bit longer. I increased the flashing duration, from perhaps a few ms, to around half a second. Rough figures, as I performed just with a decrementing count loop.

And miraculously, our board then started powering up, without issue, reliably, every time !

I then investigated further, and increased the loop duration x100, and timed with a stopwatch, to get an idea of loop count value correspondence to duration (remember, this loop is before DAVE_Init( ), so there are none of the usual facilities for timers, etc, available yet).

Once I'd worked out the correspondence, I reduced the loop count value back, to around 100ms, and then reduced further, in steps of about 5ms. And found, that our board powered up OK with 83ms, but not with 80ms. So I set the loop to 100ms, to allow some margin.

As for the cause, or rather the need, to wait this long, that is unclear, presently. The Infineon Relax XMC4800 board, with it's Micrel KSZ8081RNA PHY, needs no such delay.

For our board, we're using a very similar, Micrel KSZ8081RNB, ie just B at the end.

The difference, because the B is what is in the company 'parts bin', so that's what we have to use 🙂

Another difference, is that our software has active control, over the PHY *RST pin, for future need, which I won't go into here.

Suffice to say, that at our main( ) start, I take the PHY out of reset. The added 100ms wait, is *before* that. After, didn't work..

Another difference, compared with the Relax board, is our *RST pin driving. Infact, the *RST pin driving for *both* boards, differs from the recommended reset circuit, in the Micrel manual, for both PHYs.

The manual, for both PHYs, indicates a minimum 10ms, between PHY VDD stabilise, and RST# pin raise, to take the PHY out of reset. We checked voltage ramp-up, and it's established within a few us, of XMC4 CPU reset remove. So why the 83ms wait is needed, is unclear.

The Micrel manual says to wait a minimum of 100us *after* *RST pin raise, before starting programming on the MIIM (MDC/MDIO) interface. SWR bit set, does not, I would have thought, cause the CPU silicon to perform programming on the MIIM interface.

Although I do indeed, do some MIIM programming, after DAVE_Init( ). But I observe no problems, with the MIIM programming. But for good measure, after the *RST pin raise, I've added an additional wait, of 1ms, to allow some margin, before the DAVE_Init( ) call. What's 1ms, when you're waiting 100ms, anyway ?

Regrettably, I've been requested to progress other areas, now. And so am unable, together with our board hardware designer, to look into the need for this 100ms wait, further.

But the good news is, the 100ms wait, before taking the Ethernet PHY out of reset, has solved the apparent problem, with failure of our board to power-up boot, without DAVE 🙂

Best regards,

David

[User12775]

Good job.

If you have some "printf" debugging option, whether by SWO or by UART, you may locate the bug a little earlier. Anyway I am glad to hear the culprit identified.