Problem with save-image on the Adafruit Grand Central M4?

#1

#elif defined(ARDUINO_METRO_M4)
#define WORKSPACESIZE 20480-SDSIZE /* Objects (8*bytes) /
#define DATAFLASHSIZE 2048000 / 2 MBytes /
#define SYMBOLTABLESIZE 1024 / Bytes */
uint8_t _end;

…

#elif defined(ARDUINO_GRAND_CENTRAL_M4)
#define WORKSPACESIZE 30720-SDSIZE /* Objects (8*bytes) /
#define DATAFLASHSIZE 8192000 / 8 MBytes /
#define SYMBOLTABLESIZE 1024 / Bytes */
uint8_t _end;

Dear @johnsondavies , I notice you are having a different DATAFLASHSIZE - but you list on your main page both to be having capacity for saving 8192 objects; is, then, this DATAFLASHIZE difference correct?

Moreover, as a side note, I am having difficulty lately with (SAVE-IMAGE) on Grand Central… (Which may or may not be an issue with uLisp.) - Essentially, (LOAD-IMAGE) just let it freeze, and I think I had not entirely used up the 8192 objects capacity when saving. - In this regard, a question: do I need to adjust somehow DATAFLASHSIZE if I change SYMBOLTABLESIZE? You told me once of the relationship between SYMBOLTABLESIZE and WORKSPACESIZE of 8:1, but is DATAFLASHSIZE also affected?

#2

The #defines are correct, because the Adafruit Grand Central M4 has a larger flash chip (8 Mbytes) than the Adafruit Metro M4 (2 Mbytes). I’ll update the table in the Performance section of the main uLisp page.

However, you’re correct that load-image seems to have stopped working on the Grand Central M4 (it’s fine on the Metro M4). I’ll investigate.

Thanks,
David

#3

Thank you!

I just wanted to let you know that a “small” image of anyway under 4000 cells seems to be saved correctly, but one of somewhat over 6300 cells - fails.

New beta version of ARM uLisp with new features for feedback
#4

Just to double-check - are you referring to the Grand Central M4?

David

#5

Yes, Grand Central M4!

#6

In uLisp Version 2.8c for the ARM processors I added support for the full 8 Mbytes of flash on the Adafruit Grand Central M4, and tested it with the procedure described below. However, when I now go back and test that Version 2.8c on the same Grand Central board, this test fails. The only thing that’s changed is that I’ve installed new versions of the Adafruit and Arduino SAMD cores in the meantime.

If anyone else can report their experiences I’d be grateful.

Test procedure for save-image using DataFlash

Enter the following:

(defvar *big* nil)

(defun make (n) (setq *big* nil) (dotimes (x n) (push x *big*)))

(defun test (n) (mapc #'(lambda (x) (unless (= x (- n 1)) (print x)) (decf n)) *big*) nil)

The function make builds a very long list, to use up most of the available workspace, containing consecutive integers.

The function test scans the list and checks the integers are correct. It prints any mismatches.

So do:

(make 14000)

(test 14000)

This should return nil with no errors printed.

Now do:

(save-image)

(It takes a few seconds).

Reset the board and do:

(load-image)

Now you should be able to do:

(test 14000)

to confirm that the list *big* was loaded back in correctly.

#7

Note: I’ve changed the title of this topic to reflect the specific problem.

#8

Dear @johnsondavies,

Confirming: I did as you proposed and it hangs… It hangs somewhere between 9000 and 9100, to be precise, far away from 14000.

#9

Thanks. By the way, I’ve tested it with an SD card on the Grand Central M4 and save-image works fine all the way up to (test 14000). Odd, because the code is pretty much identical.

#10

Confirming the same!

Actually, then for the time being, I am going to opt for the SD-card…

#11

I think I’ve found the problem. Please try changing the definition of FlashBeginWrite() to:

void FlashBeginWrite (int blocks) {
  FlashBusy();
  // Erase 64K
  for (int b=0; b<blocks; b++) {
    FlashWriteEnable();
    digitalWrite(ssel, 0);
    FlashWrite(BLOCK64K);
    FlashWrite(0); FlashWrite(b); FlashWrite(0);
    digitalWrite(ssel, 1);
    FlashBusy();
  }
}

Hope that does the trick!

David

#12

Dear David,

I confirm that (make 14000) etc. DO WORK after your patch. Thank you very much for handling this so quickly!

#13

That’s great news! I’ll release a new version soon.

David

#15

This is fixed in ARM version 3.0b.

#17