I am working on Cortex-M4 over serial wire debug protocol, i am able to read IDCODE(0x2ba01477) which is correct as per arm cortex m4 technical reference manual, and i am writing 0x50000000 to CTRLSTAT register to enable CSYSPWRUPREQ and CDBGPWRREQ which is also success without any ACK error,but the thing is when i am trying to read the CTRLSTAT register i got 0xffffffff . I don't understand what might be the problem,Please suggest me what would be the problem??
Thanks & Regards
Hi and welcome to the community.
Which tool are you using for reading the data ?
(Maybe OpenOCD - or your own ?)
-Can you provide some extra information about the microcontroller vendor and model number ?
(it might be helpful in finding out the cause and thus the solution).
Thank you for responding, and by the way i am using stm32f407vg as host and stm32f407vg as target .i am trying to implement debug functionality so that i could access/control target from host. i put a step forward with Mark's Space: Programming internal SRAM over SWD blog.
i am taken 2 gpio pins configuration as follow
/* preparing GPIO pin to SWDIO */
GPIO_PIN_DATA_t st_gSWDIOPin =
/* Preparing GPIO pin to clock */
GPIO_PIN_DATA_t st_gSWDCLKPin =
as a first step i send signals from host to target and able to read IDCODE,and even i am able to write CTRLSTAT register with value 0x50000000 but when i am trying to read CTRLSTAT .I got ACK success but while i am reading i got 0xffffffff,
hoping thins information might helpful to you for my problem
Thanks & Regards.
thank you for suggestion,
after sending the key to FLASH_KEYR register
FLASH_CR = 0x80000000
FLASH_SR = 0x000000c0
Thanks & regards.
Hmm, at least you can read the registers.
I'm about to run out of ideas, but maybe it will help, if you try inserting dummy-clocks (for instance 50 zero-bits) between writing the unlocking-sequence, like this:
Write the first word, send 50 dummy-clocks, write the second word, send 50 dummy-clocks, read CR, read CR.
thanks for quick reply,
i got error resolved, the problem is each time while writing i selcting CSW register, with out that i wrote the following sequence
setting CSW register with proper bit settings then
TAR = FLASH_KEYR
DRW = KEY1
DRW = KEY2
now i am reading
FLASH_CR = 0x00000000
FLASH_SR = 0x000000C0
i wrote data to flash memory as following procedure
checking BSY bit in FLASH_SR register wait until this bit is cleared.
setting PG bit and 32bit selection by
FLASH_CR = 0x00000201
after that I am trying to read the FLASH_CR and FLASH_SR register
but i got as following
data is not updated on FLASH_CR register???
my doubt is after halt and reset no registers are modified why??
Try writing 0x00000200 first, then 0x00000201.
read 0x40023c0c (FLASH_SR)
read 0x40023c10 (FLASH_CR)
0x40023c10 = 0x00000200;
0x40023c10 = 0x00000201;
-But before that, I think it would be a good idea to read FLASH_OPTCR (0x40023c14) and check that it allows you to write to the Flash-memory.
This could also be a power issue. Make sure VOS in PWR_CR is set to Scale1 mode. (there's also a VOS_RDY bit you'll have to wait for)
thank you sir,
i tried your above approach i got FLASH_OPTCR = 0x0FFFAAED , and PWR_CR = 0x0000C000. is there any wrong with these values??
Thanks & Regards,
FLASH_OPTCR looks good to me; excellent!
I think your PWR_CR looks good too. Mine is also 0x0000c000.
I think I'll have to call for jyiu's help now, because I've run out of clues what can be wrong.
Although we're dealing with a problem specific to the STM32F407 at the moment, I just came across this document from ARM about the Debug Interface Architecture: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0031a/index.html
-You can download it for free; you just need to register first.
err....sorry.... I don't think I can help in this STM32F4 specific question.
My suggestion is to post this on STM32 forum and see if anyone there can help.
Well, it was worth the try, thank you for taking the time to look at it, Joseph.
harshan_behra -This is a very special case, only very few people have been working with it, so there might not be many people who can answer.
That means you're in pioneer-land, which is one of the most interesting places to be, but also one of the most difficult places to be at the same time.
If / when you find the answer, please let us know what caused the problem.
I just looked in the sources for the stlink tool. This might bring you to the solution.
In the file "stlink-common.c", line 1593 ...
After the sequence you mentioned, it writes a small piece of code into the SRAM and executes it.
This piece of code copies a data block from the address that register r0 points to, to the address that register r1 points to, the length of the data block is r2 bytes.
So this small piece of code can be used for both reading flash memory and writing flash memory.
In the same file, line 1765, you'll find the routine (run_flash_loader) that sets the parameters and runs the piece of code in SRAM.
The routine, which sets the value of a core register is also interesting, it's called stlink_write_reg, and is actually located in stlink-usb.c as _stlink_usb_write_reg at line 680.
Thank you sir,
I found the bug and fixed it, the bug was i have to check each time whether BSY bit in FLASH_SR was set or not that makes the consistency. Thank you for your valuable suggestions and support
Excellent news. Thank you for letting us know and also that you kept going when it wasn't easy.
I am very convinced that this will be valuable help for anyone who implements the SWD protocol in their own applications.
I do not have any flowchart myself, but I do have some important information, which you will need, in order to unlock the device.
The RM0090 is a great help here. it may not be a flowchart, but I think you might be able to pull the entire programming off by using RM0090 as reference.
One thing I know you would benefit from, is to make a "block write"; eg. create a small function, which sends data to the target. For instance:
uint32_t write_block(const char *aDataBlock, uint32_t aLength);
A function like this should check the FLASH_SR register for errors. For instance, bit 4, WRPERR means that the target is write-protected., but there are other errors that can occur as well. Bit 16 is the BSY bit, and means that an operation is in progress; you'll have to wait until the BSY bit is cleared, before you issue another operation. (see section 3.9.5 for the F405 and F407 - note: there are also information about the F41x, F42x and 43x devices, so make sure you read the correct sections).
You'll need to familiarize yourself with these registers (I've included some example values from my device):
0x40023C00, FLASH_ACR: 00000000
0x40023C04, FLASH_KEYR: 00000000
0x40023C08, FLASH_OPTKEYR: 00000000
0x40023C0C, FLASH_SR: 00000010
0x40023C10, FLASH_CR: 00000004
0x40023C14, FLASH_OPTCR: 00aaaae1
0x40023C18, FLASH_OPTCR1: 110000c0
You can find detailed information about them in RM0090, section 3.
The first thing you want to know, is what is in the FLASH_CR register.
You then want to know how to unlock the FLASH_CR register (by default, it has bit 31 set, which is a lock-bit. You can't just write a zero to this bit, you'll have to ask the microcontroller to zero it for you).
The following two commands are commands I've used in OpenOCD, they read and write 32-bit values.
The 'mww' command means Memory Write Word.
The 'mdw' command means Memory Display Word:
First you'll want to read FLASH_CR (this sequence is shown in section 3.6.1 and is essential, before you can proceed):
Next, you'll want to write the value 0x45670123 to FLASH_KEYR, then write the value 0xCDEF89AB to FLASH_KEYR.
mww 0x40023C04 0x45670123; mww 0x40023C04 0xcdef89ab
After this, bit 31 in FLASH_CR should be zero (we'll start by displaying the FLASH_SR register to see if there were any problems):
mdw 0x40023C0c; mdw 0x40023C10
You're now allowed write access to the FLASH_CR register, but you're not allowed to change the option register.
To do so, you'll need to write a sequence to the FLASH_OPTKEYR, followed by a write to FLASH_OPTCR, which will unlock your Flash-memory.
Note: You do not need to unlock FLASH_CR, if you only need to work with FLASH_OPTCR.
First, let's see the contents of the option register, followed by the FLASH_SR register:
mdw 0x40023C14; mdw 0x40023C0c
I recommend reading the old value of FLASH_OPTCR, parsing it and writing back a new value with the bits set for the sectors you want to modify, in case you need to set any bits. Perhaps they're already set, and if they are, it's a good idea not to change the register contents.
This is the sequence that unlocks your Flash-memory (see section 3.7.2):
mww 0x40023C08 0x08192A3B; mww 0x40023C08 0x4C5D6E7F; mww 0x40023C14 0x0fffaaed
mdw 0x40023C0c; mdw 0x40023C10; mdw 0x40023C14
You will need to "mass erase" (section 3.6.3) before you write your program data (section 3.6.4).
These sources might be helpful (I didn't have a look at them yet):
git clone https://github.com/texane/stlink.git
may i know where could i found detailed explanation about watch points and break points ?? in reference manual he given a little bit but i need in programmer view where could i get such information??
Unfortunately I'm not an expert in this area, so I don't know much about breakpoints and watchpoints.
I went to the ARM Information Center and searched for 'watchpoint', as this is not technology specific to the STM device, but it's ARM technology.
Scrolling down, I find the results for ARM Cortex-M4 Processor Technical Reference Manual, I click it, and I click the DWT Programmers Model link in there.
This shows addresses of hardware registers.
If you look at CWT_CTRL, it says "See [a]", which refers to a note giving you some more information: There are (up to) four comparators for watchpoints and triggers.
In RM0090, sectino 38.13, you'll find some information about what's implemented in your device, combining this with the information found in the Cortex-M4 Technical Reference Manual should get you a bit further.
Please try ARMv7-M Architecture Reference Manual. You need to register on ARM web site to download this document.
(ARMv7-M Architecture Reference Manual)
Section C 1.8 for DWT (watchpoint), C 1.11 for FPB (breakpoint) and C 1.6 for debug registers in the processor for halting control.
View all questions in Embedded forum