[bugfix-2.0.x] EEPROM Read problem #12442
Comments
|
Have you been using Marlin before on this board? If so how old was the version you previously had? Did the eeprom work then? Have you had other software installed on the board? Can you try the following.... Send M502 followed by M500 repeat this at least 8 times and then try an M501. |
|
The board (Azteeg_X5_GT) work fine on dc11131 (Tue Sep 25 2018) |
|
Can you go back to that older version and edit the persistent_store_api.h in the LPC1768 HAL to enable the use of flash for eeprom storage then try things again? You should get some debug output. |
|
ok: AND current 7a075a5 i think problem with EEPROM write AND current work fine with SD store ... |
|
Unfortunately I can't debug this at the moment. Is there any chance you can copy the file persistent_store_flash.cpp from the older build (the one that works and that produces debug) and use that version of the file in the current version of Marlin? That way we should see the write debug from the HAL (if there is any). |
|
OK I've just spent a couple of hours trying to reproduce this and nothing I can do will make my LPC1768 based SBase board do anything other than work fine. Having said that this is the 2nd report I've seen in which LPC1769 based systems have some sort of issue with storing eeprom in flash. The other report only had issues with storing a mesh not with storing the other settings. I have a feeling that if there is a problem it is somehow timing related. The only slightly odd thing I've seen is that the framework actually calls the PrepareSector function for you so the calls in the Marlin code are not really needed, perhaps doing this operation twice is causing some issue? So can you try commenting out the calls to PrepareSector in the Marlin code and rebuilding. @p3p do you have an LPC1769 based board? Any chance you can try and reproduce this problem? @thinkyhead While investigating this I noticed a couple of odd uses of the persistent store API by the configuration store code. The first issue is that in load_mesh there is the following code: int pos = mesh_slot_offset(slot);
uint16_t crc = 0;
uint8_t * const dest = into ? (uint8_t*)into : (uint8_t*)&ubl.z_values;
persistentStore.access_start();
const uint16_t status = persistentStore.read_data(pos, dest, sizeof(ubl.z_values), &crc);
persistentStore.access_finish();
if (status)
SERIAL_PROTOCOLPGM("?Unable to load mesh data.\n");
#if ENABLED(EEPROM_CHITCHAT)
else
SERIAL_PROTOCOLLNPAIR("Mesh loaded from slot ", slot);
#endif
EEPROM_FINISH();It seems to me that this is incorrect as the EEPROM_FINISH will be calling persistentStore.access_finish(); which has already been called. So you end up with a finish being called without the matching start. The second issue is that when UBL is active and there is an active mesh then a call is made to the above load_mesh code to load the active mesh. However this call is made inside of the EEPROM_START, EEPROM_FINISH pair, this creates a nested call to the persistent store api, is it intended that this is valid? It is noticeable that the code that writes the data to eeprom takes care to avoid this nested call. So the sequence is on write... persistentStore.access_start();
// write main config
persistentStore.access_finish();
persistentStore.access_start();
// save mesh
persistentStore.access_finish();But on read it looks like... persistentStore.access_start();
// read main config
persistentStore.access_start();
// read mesh
persistentStore.access_finish();
persistentStore.access_finish();Should this second form be valid? At the moment it does not cause a problem for the LPC1768 read code, however if the same pattern was used for the write code it probably would. |
|
No I don't I'm afraid, The only thing it can be is timing there is no difference in the MCUs other than the clocks, sorry I can't be more help on this tbh I would love a break from staring at PWM signals I've just about lost my mind in trying to figure out that problem. |
|
I have exactly the same issue. I Tried the same thing the commit of Sep 06 2018 and it works fine, but the latest one does not. I use the SD card as eeprom. Tomorrow I will try commits in between to narrow it down.
|
|
If you use the SD card as eeprom you will not see the problem. The 6th September version uses the SD card by default, the later build will use flash memory. So if you just want to get going you can change the setting in the persistent_store_api.h file of the current build. If you want to help and debug this issue then please try the following...
Thanks for your help. |
|
So default of current build is flash memory. How can I let it use the sd card in the current build? Maybe I can check this first. Then I can try to reproduce your described steps. |
|
See the comment above. You need to comment out the line #define FLASH_EEPROM in the file persistent_store_api.h in the HAL_LPC1768 directory. |
|
|
Can you try changing a value in the framework for me: I'm not sure this will help as the system files are almost direct copies from smoothieware but the current value seems to be wrong only supporting upto 80Mhz, The manual specifies 4 (5 ticks) should work at 120Mhz as well as the 100Mhz noted in the comment. |
|
The debug output is interesting, looks like there may be an alignment issue can you edit the persistent_store_flash.cpp file and change the following line... static uint8_t ram_eeprom[EEPROM_SIZE];to static uint8_t ram_eeprom[EEPROM_SIZE] __attribute__((aligned(4))) = {0}; |
|
Setar, do you have a LPC1769 or LPC1768 board. I have a LPC1769 board and with all builds I get this message: echo:EEPROM version mismatch (EEPROM=? I tried all suggested options and get the same result. So maybe it is an issue with the LPC1769 |
|
@stefan85 Did you try the change I've just posted above (the code change that adds data alignment)? Did you try using the older version of the persistent_store_flash.cpp file (the one with extra diagnostics in it)? If you did please post your output. Note that you will get the error you mention until you actually store a valid config in flash. So be sure to test both a write operation and a read operation. |
|
That was really strange. I did the following steps:
I don't know if it is any help but it seems to be issues with first use of the eeprom in my case. |
|
Actually I suspect that your new version is not working (or if it is it is just down to luck because the alignment of the ram buffer just happens to end up correct). Have you tried actually changing some of the eeprom contents and checking that the new values are correct after storing and loading? The problem in the logs above is during a write operation and results in the existing content not being changed. This error is not reported by the current Marlin build and so you may not realise that the new values have not been saved. |
Azteeg X5 GT by design have LPC1769, but for build i use pio run -e LPC1768 -t upload old versions are stored in both stores (EEPROM and SD), which can be seen from the version mismatch when reading in the new firmware: |
not work: |
Bingo! check |
|
UBL Mesh store to EEPROM also work fine: |
|
Cool. Seems like this also should solve #12407 |
If you have a LPC1769 you should build with |
|
ок, |
|
Thanks for testing this I'll put together a PR for the changes later today. |
|
fix work fine, thanks |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
bugfix-2.0.x , 7a075a5
my config : https://github.com/setar/Marlin/tree/bugfix-2.0.x-3ntProf_v10_AzteegX5_short_Yhead
EEPROM Read problem:
for debug i try define DEBUG_EEPROM_READWRITE but no result.
Any idea for debugging ?
The text was updated successfully, but these errors were encountered: