Sir,
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
Thank you for code snippet sir,
i followed ur sequence , but the story remains same.
IDCODE success,
ABORT write success,
CTRLSTAT = 0xffffffff with parity error ,
i got same response even i changed pullup 10k to 100k.
... Uhm wait ... You use STM32F4 Discovery, right ?
If so, did you remember to disconnect the on-board SWD programmer ?
-If not, it might interfere with your results.
I tried grabbing the data using my analyzer, and I can't seem to map them properly to the documentation and experience of for instance Mark.
These are the first 400 bits of the transfer:
11111111111111111111111111111111111111111111111111111011110011110011111111111111
11111111111111111111111111111111111111111100101001011001110111000101000000001011
10101000011011000110000000000000000000000000000000100111100101011000100000000000
00000000000000000101001011000110000000000000000000000000000001111001100011011000
10000111100000000000000000000000001111100110000000000000000000000000000000000001
Note: When using HLA_SWD on STM32F4, I get 53 leading ones and 53 trailing ones, but when I use JTAG-lock-pick Tiny 2 with LPC1751, I get 50 leading ones and 50 trailing ones.
What looks odd to me, is that it looks like there is no turnaround!!
-But also according to the documentation found here, there should be turnaround: http://www.arm.com/files/pdf/Low_Pin-Count_Debug_Interfaces_for_Multi-device_Systems.pdf
I get IDCODE 0x2BA01477 for both STM32F4 (which is a Cortex-M4 device) and LPC1751 (which is a Cortex-M3 device).
Here's a similar session with JTAG-lock-pick Tiny 2 and LPC1751:
11111111111111111111111111111111111111111111111111011110011110011111111111111111
11111111111111111111111111111111111100101001011001110111000101000000001011101010
00111000000110011011110000000000000000000000000000000000001011000110010000010000
00000000000000000111101110010101100110000010000000000000000000000000011011000110
00000001000000000000000000000000011110010101100110000000000000000000000000000101
In both cases, it seems there's no turnaround clock. So I believe that right after sending the last bit, before changing the SWCLK to LOW, you could try and change the SWDIO direction to input, then issue the SWCLK_LO and have 0 turn-around clock cycles.
According to all the documents I found, it seems that data are sampled on the rising edge of SWCLK, thus changing the direction should be done right after you've sampled the data.
So far, I have been unable to do a test with the JTAG-lock-pick Tiny 2 connected to the Discovery board, but if I get it set up, I'll post the output here as well.
thank you for reply sir,
i got the CTRLSTAT register correct , The problem was with the parity bit calculation , I corrected that one. Now I am able to halt and reset the core from host to target successfully. Now i am trying to write data into flash memory region. may i know an algorithm or flowchart approach to write hex file to flash memory??
Thank you sir,
Sir I am able to write data to core register like r0,r1,r2........ but when I am trying to read it back, i got data as 0, my reading and writing procedure as following
writing
selecting bank0
writing data to DCRDR
writing address to DCRSR
waiting until S_REGRDY bit in DHCSR register was set
reading
reading data from DCRDR
my approach
core halt & reset
write into register
read from register (where i wrote)
It looks like you've come a long way.
I think, that at this time you may know much more about all this than I do.
-So I think we'll need to call for a SWD-expert in this case.
,
after writing into flash if i am trying to reading from the flash address i got 0xffffffff i don't know why that happening ??
Thanks & Regards.
Thanks for Reply sir,
in above post you wrote "0x40023c04=0x45670123. 0x4002c304=0xcdef89ab" hear both addresses are different , in stm32f4 reference manual 3.6.1 he mentioned that both keys 0x45670123 and 0xcdef89ab should be send to FLASH_KEYR(0x40023C04) register please make a clarity on that and another thing is my flash Unlock was unsuccess full.
my procedure was
halt
reset
reading status of FLASH_CR register if LOCK bit is set then
sending 0x45670123 and 0xcdef89ab to FLASH_KEYR register.
delay: for loop ->1000
then reading status of FLASH_CR register.
Thanks and Regards.
Most likely your Flash memory is protected.
It's important that you know there are two unlock sequences.
First you will need to check that the LOCK bit of FLASH_CR is zero. If it is not zero, you will want to unlock it by sending the unlock sequence mentioned earlier:
0x40023c04=0x45670123. 0x40023c04=0xcdef89ab.
Then you may need to wait for a few milliseconds; I do not know how long, but try giving it a good delay at first, then you can reduce it and see when it fails.
Now read FLASH_SR first. It is important to check all the things in this register that can go wrong. In particular, we're interested in bit 4, the WRPERR bit.
-If the WRPERR bit is set, we're in trouble, but we'll also need to be free of other errors.
If there are no errors, however, then we can proceed and read FLASH_CR again, to verify that the LOCK bit is now zero.
If the LOCK bit of FLASH_CR is zero, then we can proceed.
Read the FLASH_OPTCR register. by reading address 0x40023c14. If this register does not contain 0x0fffaae1, then you'll most likely get write protection errors in FLASH_SR after attempting to write to the flash-memory.
So if FLASH_OPTCR register's bits 27:16 are not all 1, then we'll need to modify them. Bits 15:8 must be 0xaa. So we'll write the following:
0x40023c08=0x08192a3b. 0x40023c08=0x4c5d6e7f. 0x40023c14=0x0fffaaed.
Right after that sequence, we should read FLASH_SR, to check for errors.
Then read FLASH_CR and verify that the LOCK bit is still zero.
After that, we should read the FLASH_OPTCR register, to verify that the value is now changed; expect 0x0fffaae1.
OK, we're about to flash-program the device, so now we'll do the checking again.
Read the FLASH_OPTCR register (address 0x40023c14), if bits 27:16 are not all ones, we can't write to the flash-memory.
Now read FLASH_SR, and verify that there were no error reading FLASH_OPTCR.
Finally, read FLASH_CR and verify that the LOCK bit is still zero (I expect that it always is zero).
If all checks out, try writing a block of data to the Flash memory.
Right after writing the last 32-bit word of your data block, you should immediately read FLASH_SR and check for any errors.
If bit 4 is set, then you could not write to the flash memory, because it's write-protected (somehow that means that the FLASH_OPTCR does not contain the value we'd expect by now).
If any of the above sequences do not contain the values I wrote, please let me know, I could have made a typo.
I'm sorry, 0x4002c304 was a typo, I believe the right address should be 0x40023c04.
Did you try reading FLASH_SR right after writing the two values to FLASH_KEYR ?
What are the values you read from FLASH_SR and FLASH_CR ?
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
idle cycle
DRW = KEY2
now i am reading
FLASH_CR = 0x00000000
FLASH_SR = 0x000000C0
after above
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.
For instance:
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.
regards,
Joseph