-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data flash not programmed #9
Comments
Indeed, data programming is not implemented. If you are OK to wait few days, I can prepare a version to try. Changes don't seem to be significant. Thanks, |
Yes, of course it is ok to wait for this. |
Please try the v0.6.0-initial-data-flash-support tag. It works for me (erase, write and verify). Regards, |
After a first test this seems to work correctly. (I had to program it with -ewc, without -r and to verify it with -dc because the software on the mcu overwrites the data flash on first run) Later I will prepare a special test file which requires the whole flash to be written, then I will be sure that this works. (because the file I tested it with had all the data flash empty (all 0xFFs)) Edited to add:
This is my test file which fills the whole flash space. It doesn't write actual code. It writes 00000.... to the first 32 bytes, 002000200020... to the next 32 bytes, 004000400040... to the next and so on: This is the result of the -ivvvvewc command: This is the result of the -ivvvvc command: Another thing I see with my test file that If there was an erase, the write fails, so every second write is a fail:
Edited to add: This are the outputs from both situations: |
Hi, I'm on vacation at the moment, and will be able to take care of the issue after the 26th of June. Regards, |
It seems the issue is in timeouts (not long enough). |
I've merged the current version to master. The feature is included in v0.6.1. Regards, |
Recently I found out that the "problem" of not programming the data flash could actually be a useful feature. I made for myself a modification of newest rl78flash where I added two commandline options: It is very useful for debugging to reprogram the data flash without changing program flash or reprogram program flash without changing data flash or just erase data flash to simulate a device that just came out of factory and was never turned on yet. Maybe it would be good to have the possibility of disabling data or program flash in official rl78flash release? |
A command line option to disable programming of data flash is very useful. Thanks! Regards, |
I'm not very familiar with github and pull requests yet. I added two commandline options. -x and -y. |
I added the possibility to disable data flash or code flash operations as commented on issue msalau#9 I added two commandline options. -x and -y. And two variables char nodata and char nocode. Using -x will disable any data flash operations. Using -y will disable any code flash operations.
I added the possibility to disable data flash or code flash operations as commented on issue #9 I added two commandline options. -x and -y. And two variables char nodata and char nocode. Using -x will disable any data flash operations. Using -y will disable any code flash operations.
I have noticed that only the code flash is erased, programmed and verified.
The data flash is not.
I looked into rl78.c and I saw things like this:
int rl78_program(port_handle_t fd, void *code, unsigned int code_size, void *data, unsigned int data_size)
{
// Suppress "unused variable" warnings
(void)data;
(void)data_size;
which suggests that this is a feature that has been skipped on purpose, for later.
I this true?
Do you have plans to implement this?
Or maybe for some reason it was not possible to implement?
It is important for me to have this working.
I want not to need E1 programmers any more.
And the devices we are programming also need the data flash to be programmed.
If you are not planning to implement this then I might consider making a fix myself.
But I'm not familiar with your code so I would not be very effective.
The text was updated successfully, but these errors were encountered: