Open vkottler opened 7 years ago
Do you need this one ? We can implement it on Friday.
Wondering if this might be done?
I want to clarify if I got it right. So you want to write anywhere but in reserved memory and in the section which covers the beginning of RAM to the end of the data section ?
That's right, essentially everything besides flash. In a perfect world we would avoid RAM where the stack might be to prevent clearing stack variables but that's not important
Main desire is to write to peripheral and core registers at run time. Would be pretty nice to have for testing driver features i.e. enable single bits at a time and see behavior
Sounds good. I think it will be enough if we will be able to write 32 bit value to some address. 1 ) What is < value > ? 2 ) What is < count > ?
I feel like count is unnecessary. Unless it is a 32 bit mask, to that we can write to specific bits.
<value>
is a word, i.e. 0xabcd0000
, <count>
was implied to be the number of words you'd like to write, incrementing by 4 from the initial address provided.
most implementations of this function allow an optional suffix:
md[.b | .h | .w]
for writing bytes, half-words, or words which would increment by different amounts but we don't need to do it this way
common/cmd_mem.c: In function 'do_md':
common/cmd_mem.c:108:17: warning: 'data' is used uninitialized in this function [-Wuninitialized]
command_status status = md_mw_input_handler(argc, argv, mem_ptr_, data, length, 0);
Why are we committing warnings? Also I think you're passing a null pointer into this function
It should not have been there. This is weird. We were fixing some bugs and were not planning to push it. This our fault.
Need to implement
md <address> <value> <count>
so we can write to data memory on the fly.This implementation should hopefully check if the memory access will be legal since not all of the virtual 4 GB space is mapped, but the alternative is to develop a robust BusFault Handler to recover from these accesses.
In addition to that, we will not be able to write to flash and for now there is no plan for this command to be able to do that. We also do not want to overwrite anything in our data section of memory, so this command should check if the access is between the beginning of RAM and the end of the data section(s) before performing any writes.