Yes, i have this problem without debugging. I.e. reset fails even without the SWD connected!!
And the only difference is that AFIO_MAPR_SWJ_CFG_JTAGDISABLE works but
AFIO_MAPR_SWJ_CFG_DISABLE fails. When having AFIO_MAPR_SWJ_CFG_DISABLE
the program starts after programming but will never be able to restart again...

The program has been grown over the 32K starter limit, I therefore normally only
use the SWD for programming. I have disabled the debug option in debug options menu
(The men where you can erase and program) and removed the starter kit limitation
option.

When needed I have been using the SWD for debugging and that has been working
fine. (I compile with small printf option and remove some part of program, that will enable
the program to fit under the 32K limit...)

(And yes, I will probably order the "not limited" debugger later on!)

Regards

Per

Hi

I thought you were debugging because you said that Ride7 lost contat with target.
Still I think it will be better to have a project to analyze the problem.
May I ask to send it to support address
If you can not send all your project you can also open an example project and introduce he problem there
and send it to me.

Regards,
Matloub

Hi,

Thank you for your patience and for the detailed reporting.
We received your project and now we understand the problem better.
In fact there are at least two distinct problems...

1. The first one is that the three SWJ_CFG bits of the AFIO_MAPR register are write-only. Reads on these bits are undefined. You can see more information on this in the RM0008 STM32 reference manual.

In short, that means you cannot perform OR operations on this register, or you must do it with extra care. So the two lines that you mention have little chance to work. In fact you cannot even expect them to produce the same result at each execution, and they might generate exceptions that will stop the execution of the application.

In the CircleOS code for our Primer demo board, we also disable JTAG because we use the pins for audio data. For that we use this library call:

GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);

I suggest you use the same procedure and see if it's better.
You can also download the complete source code of the CircleOS on this website:
http://www.stm32circle.com
The JTAG disabling is done in file "audio.c".

2. The second problem is, as you say, that the content of the code should not affect the behavior of the programmer until the code execution is launched. I could reproduce this problem and we will correct it in the next release of the software.

Until then, I suggest you stop using the Debug Options window for programming. Instead you can use either RFlasher7 or Cortex_pgm, that both have a "launch" command which is completely independent from the "Program" command, and therefore this problem will not appear. I just checked that the following command does NOT launch the application execution after programming it:
cortex_pgm TSTM32F103RBT6 R E B PSTM32F103_toggle.hex

I also checked using RFlasher.

Well, that's it for now.
I hope it helps.
Please tell us know if there are other problems.

Best Regards,

Vincent

1) I realise that the reading and doing an "or" was not correct on the bits for the SWJ_CFG. Thanks.

Anyway, the GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE) gives the same behavior.
The code starts to run efter programming, but I can't reset the STM, then it never seems to restart.

(The line AFIO->MAPR = AFIO_MAPR_SWJ_CFG_JTAGDISABLE also give the same behavior)

2) Just want to be sure that I understand you correctly... Regarding the programmers behavior... After
the error with "Error reported by DTC", the program starts to run, but as described above, I can never
restart the STM with the reset button (with our without programming pod). From my point of view
the GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE) or
AFIO->MAPR = AFIO_MAPR_SWJ_CFG_JTAGDISABLE is causing some strange behavior with RIDE7 and
its programming.

Anyway, programming it with RFlasher7, then the program starts OK (as you write)!

Best regards,

Per

Hi,

Your test with RFlasher tells us that there is no problem with the programming itself.
I mean the writing of the data in the flash; and this part is the same code for RFlasher and for Ride.
If you want to be sure about that, you can use the Verify or Read commands of RFlasher to check that the flash content is as expected after programming using either Ride or RFlasher.

I think that the first problem appears during the _execution_ of the application because of something in the code of the application. It probably executes until it reaches those lines which for some reason crash it.
Note that UART sends might be delayed by the hardware, so you cannot trust them to make the difference between an application that does not reset and an application that starts but crashes after some time.

The second problem is in the Program button of Debug Options window:
just after writing the data (which works fine), and before asking if you want to reset,
because of a typo in the code of the window it executes the application for a few milliseconds,
which results in the triggering of the first problem, which in turn results in the 'DTC error' message.
In the next version it will not execute the application at all unless you ask it to, and the error message will not appear at all.

So now you should ignore the second problem (just stop using this button; use RFlasher instead) and focus on understanding the first problem, which I think is NOT related to programming and maybe not to reset either, but more probably to the execution of the application...

I tried your faulty lines on examples for STM32F103RB and STM32F103ZE and observed no issue.
I will need more time to find a board with a STM32F101RC like yours.
But the STM32F103ZE is very similar to the STM32F101RC, so I'm starting to suspect that the problem might be also in relation with something on your board.
Can you please send more information on your board to "support@raisonance.com"?
Are you using a commercial demo board (give us the reference) or a custom board (send us the schematic)?

As I mentioned above, you should not trust UART sends to test these issues.
I suggest you modify your test to light a LED and wait at least one second before remapping the debug pins, then light another LED and go on with the rest of the application.
That will tell us if the application starts for some time and fails when the remapping is made, or if there is really a problem with the reset.
And it will be easier for me to port it on another board.

Best Regards,

Vincent

I have tested what you proposed, the programing are identical whatever if it is programmed with Ride or RFlasher. Though, I can't do a manual reset after programming with Ride. However, if I power cycle the board (when the reset has stopped working), then reset starts to work. (I have a led indication also on the board)

As a second test to check if the program run or not, I have tested to indicate on a led before I do the remapping GPIO_PinRemapConfig(GPIO_Remap_SWJ_Disable,ENABLE) and the "reset fail" problem will not occur. Investing little deeper, it is enough to have a delay before issuing the remapping... If I add a delay before the remapping, I don't either get the problem:
SysTick_Config(SystemFrequency / 1000);
delay_ms(100);
GPIO_PinRemapConfig(GPIO_Remap_SWJ_Disable,ENABLE);

(Removing the delay will trigger the problem again)

To summarize: It seems that when the RIDE7 software fails to do the reset due to remapping and I get the
"Error reported by the DTC", it is impossible to reset the circuit. The programming are anyway correct and a
power cycle will get the reset to work a again.

I will send a schematic.

Hi,

Thanks for the information. Just a few more questions...

Does the "Error reported by the DTC" message appear when you perform an operation that is NOT from the Debug Options window?
If yes, which operation? (I mean which button or command of which window of which software, or which command line?)

Does the "reset fail" problem appear when you perform an operation that is NOT from the Debug Options window?
If yes, which operation? (I mean which button or command of which window of which software, or which command line?)

Best Regards,

Vincent