@evanh said:
... Where does Catalina hubRAM use start at?
Just looking at the .lst file and it looks like the answer is $1000 (4 kB). Everything before that looks to be cog0 cogRAM.
Yes, that's usually the case. However, I have a vague memory of using a 256 byte buffer in that low RAM area for something - either in another plugin, or perhaps for loading XMM programs^ - which is so complex it makes my brain hurt just at the thought of having to revisit it
But you should be fine to use it in this case for debugging.
Ross.
^ EDIT: Did a quick search, and couldn't find anything like this. It may have been something I later decided to remove.
Thanks. I've started poking but nothing strongly stood out. The init is completing without error. The CID and CSD do get a different set of numbers but aren't gibberish. Haven't worked out why as yet.
I've made a bit of a mess of the driver so might start over.
@evanh said:
I've made a bit of a mess of the driver so might start over.
Thanks for the efforts. You may be interested to know I have recompiled all Catalyst programs (including Catalina itself) to run at 300Mh using my driver with an SD card delay of zero, and have been doing extensive testing of Cake with it, which (amongst other things) means doing lots of test compilations on the Propeller 2 itself. And I have not seen any SD card lockups since the first few instances.
This is the problem I always seem to have with SD cards - they can work flawlessly for a long time, but occasionally they fail for no apparent reason. I have often wondered if it is the P2 SD circuitry itself, which shares pins between FLASH and SD, and even thought the flash is disabled when the SD card is in use, there may be an issue there - something which your experiences when using different pins for the SD card might also point to - but I am not hardware-savvy enough to really say, and nor do I have the tools to see what's happening at the hardware level
The SD/Flash sharing arrangement is pretty bad. It causes strange issues for everyone. It appears most people building custom boards with SD card slots are going for separate pins or 4bit i/f now, at the expense of SD boot.
@Wuerfel_21 said:
The SD/Flash sharing arrangement is pretty bad. It causes strange issues for everyone. It appears most people building custom boards with SD card slots are going for separate pins or 4bit i/f now, at the expense of SD boot.
I only have P2 Edge and P2 Eval boards, but Catalyst can be booted from FLASH instead of from the SD^ - I will try that configuration for a while and see if it makes a difference.
^ To boot Catalyst from FLASH (but also still use the SD card) you set the FLASH switch to ON and the P59^ & P59v switches both OFF. Insert the SD card, but then use flash_payload. For example: flash_payload catalyst.bin -i
More details in the Flash Support section of the Catalina Compiler Reference Manual for the Propeller 2
@evanh said:
Thanks. I've started poking but nothing strongly stood out.
Ahhh, I've struck this before. Many SD cards have an internal pull-up on the DO pin, but some don't. Or maybe none do, dunno. At any rate, there is a specific active pull-up in my edited version of the sdmm built-in driver in Flexspin. I keep forgetting it has that. The 4-bit SD mode driver doesn't need it because the add-on board has pull-up resistors on every pin.
When I'm testing non-boot pins I'm using the 4-bit add-on board with the wired pull-up resistors, making the issue go away.
@evanh said:
At any rate, there is a specific active pull-up in my edited version of the sdmm built-in driver in Flexspin.
I don't understand this bit. How do you implement the pull-up in software?
Configure the output drive to 15K ohms, then drive it high. Or better still, DRVL and use the invert pin drive. Then it happily acts as an input with a pull-up.
Right, good reminder, I gotta get motivated to see if it solves everything or not ...
Hmm, I've just realised I'm getting the identical behaviour with Flexspin's sdmm driver too. It's only happening with one of my uSD cards (Sandisk Extreme 64 GB, dated 2024) and only on the boot pins. Put that same card in the 4-bit add-on slot and no problem with it either. Same for both Flexspin and Catalina compiled programs. The pull-up on DO doesn't appear to be the issue, although without it sdmm can't init any SD card.
Specifically, on every second init sequence the 64 GB SD card is reporting from CMD58 as byte addressable SDSC, and only 30 MB capacity reported in CSD register (CMD9). The card seems to change config somehow. And has probably always done this but I only just noticed first when testing with Catalina.
Solved. I've moved R802 to R801 position on the Eval Board, permanently enabling the voltage regular that powers the boot SD slot and Flash EEPROM. This prevents the reset circuit from power cycling these parts.
PS: I now see another reason I'd hadn't been seeing this earlier. The older Eval Board I have, which is the one I've done most testing with, I'd already moved R802 long ago.
Ross,
There's a chance your random file corruption could be because of this same poor power cycling - Which occurs on each download. I recommend making the wiring change just to take the possibility off the table.
@evanh said:
Ross,
There's a chance your random file corruption could be because of this same poor power cycling - Which occurs on each download. I recommend making the wiring change just to take the possibility off the table.
Sadly, I don't have the tools to do it even if I had the eyesight. Also, what would be the equivalent on a P2 Edge board?
@RossH said:
... Also, what would be the equivalent on a P2 Edge board?
Ah, it doesn't do the power cycle on reset at all. The SD slot and Flash EEPROM both are supplied direct from the V5663 LDO regulator, whcih in turn comes straight off the common 3.8V switching regulator. Okay, sounds you're getting the identical behaviour on both Eval and Edge. Which then means you're dealing with a different issue than me.
PS: It's the same for most of the EC and EC32MB revisions. The original EC rev A uses a diode drop from 5 Volts instead of the switching regulator for the common to the LDOs but otherwise is the same.
I only have P2 Edge and P2 Eval boards, but Catalyst can be booted from FLASH instead of from the SD^ - I will try that configuration for a while and see if it makes a difference.
^ To boot Catalyst from FLASH (but also still use the SD card) you set the FLASH switch to ON and the P59^ & P59v switches both OFF. Insert the SD card, but then use flash_payload. For example: flash_payload catalyst.bin -i
More details in the Flash Support section of the Catalina Compiler Reference Manual for the Propeller 2
Just thought I'd add a postscript to this. I have been booting Catalyst exclusively from FLASH for over a week now, and running at 300Mhz and with an SD write delay of zero, and have seen no SD card lockups. I have tried two different SD cards (a Verbatim 8Gb and a Sandisk Extreme 32Gb). I have been running extensive Catalina and Cake compilations which make heavy use of the SD card file system, and which can run for up to an hour.
My tentative conclusion is that the SD card lockup occurs on booting from the SD card only.
Another benefit of booting from FLASH is that it speeds up Catalyst as a whole, particularly programs that rely heavily on script execution (such as Catalina itself). For example, here are my current Catalina compilation times on my P2-EC32MB:
I am yet to decide whether or not to make zero the default delay on SD writes - currently, it is still 10ms. I think I will leave it at that for the next release, but it is configurable on the Catalina command-line, so you can easily set it to zero.
This is a full release. It updates Cake, makes the SD Card write delay configurable, enhances Catalyst, and fixes a few minor issues.
Here is the relevant extract from the README.TXT:
New Functionality
-----------------
1. A version of dirent.h, which defines the functions opendir(), readdir(),
closedir() and realpath(). These functions are not part of any C standard,
but are required by Cake.
2. Cake has been updated to version 0.12.55.
3. Catalina now disables Cake's use of colors in error and warning messages
by default, because Geany does not support it. However, for command-line
or terminal emulator use, colors can be re-enabled by defining the Catalina
symbol CAKE_COLOR, e,g, by adding -C CAKE_COLOR to the Catalina command.
For example:
catalina hello_99.c -lci -C99 -C CAKE_COLOR
4. printf() (and fprintf() etc) now supports "ll" as a length specified, to
indicate a long long - for example "%llu" indicates an "unsigned long long".
Note that in Catalina long longs are the same as longs, so in practice both
"%lu" and "%llu" will now do the same thing, whereas in previous releases
the former would have printed 100 as "100", whereas the latter would have
printed it as "100ul". This change was required to support Cake.
5. The Propeller 2 SD card driver (/target/p2/cogsd.t) now allows the SD card
delay (in clock ticks) to be specified using the Catalina symbol SD_DELAY
during compilation. For example, to set it to zero use a command such as:
catalina -p2 -lcx program.c -C SD_DELAY=0
Defining the Catalina symbol NO_SD_DELAY also sets the SD_DELAY to zero,
but can be used in build_all scripts. Using NO_SD_DELAY overrides any
other specified SD_DELAY.
The default if not specified is 10ms, and the driver may not work properly
if this delay is altered.
6. In the Catalyst demos folder (demos/catalyst) there is now a build_p2_300
script, which builds Catalyst using a 300 Mhz clock speed (the default of
200Mhz is still used by the build_p2 script). So for example, building
Catalyst at 300 Mhz and with no SD_DELAY can be done with a command like:
build_p2_300 P2_EDGE PSRAM NO_SD_DELAY
Note that 300 baud and no SD_DELAY may not work for all programs, all SD
cards, or all Propeller 2 platforms.
7. Catalina no longer defines the symbols "win32", "_WIN32", "_M_IX86" "unix",
"i386", "linux" "__unix__", "_i386__", "__linux__", or "__signed__"
automatically on any platform. Not defining these symbols may make some
programs either not compile, or behave differently. If any of these symbols
are required, they can be defined on the command line (using -D).
For example:
catalina program.c -D__signed=signed
8. Catalina no longer defines the C symbols "__STRICT_ANSI__" or "__STDC__"
automatically because this can interfere with the use of Cake as the C
preprocessor. Not defining these symbols may make some programs either
not compile, or behave differently. If these symbols are required, they
can be defined on the command line (using -D). For example:
catalina program.c -D__STDC__=1
The C symbol _POSIX_SOURCE is still defined even though Catalina is not
fully POSIX compliant, because this symbol enables some necessary
definitions in the C header files.
9. The -u option to catalina means it does not delete intermediate files.
This is sometimes useful for debugging. On Catalyst (only) it now also
means to not run the pstrip utility, which 'strips' comments and blank
lines from the intermediate source code files (to reduce their size).
10. Allow -C USE_COLOUR to enable Cake's use of color (i.e. in addition to
-C USE_COLOR) and also use the Cake option -fdiagnostics-color=never to
disable the use of color.
11. The Catalyst "ls" command has been enhanced to add -a as a command line
option. This option includes ".", "..", volume ids and system and hidden
files in the listing output, which are now otherwise not included.
Also, directory contents are now listed for any directories specified by
the command line parameters (previously, a trailing "/" had to explicitly
be added to a directory name to print the contents of the directory).
Now including a trailing "/" means to list both the directory AND the
directory contents. So, for example:
ls /
will list the contents of the root directory and also the contents of
any subdirectories, whereas:
ls
will list just the contents of the root directory. Similarly:
ls -l bin/
will list the long details of the bin directory and also the long details
of the contents of the bin directory, whereas:
ls -l bin
will list just the long details of the contents of the bin directory.
Note that the -r flag can be used with or without a trailing "/" on the
directory names.
Fixed the column and line counting, so the "Continue?" prompt works
properly.
12. The Catalyst ls and cat utilities now autodetect the screen size if the
VGA, TV and VT100 compatible serial terminal HMI options are used (for
serial terminals other than a VT100 compatible terminal, screen size is
assumed to be 80x24).
Other Changes
-------------
1. The C include file limits.h (i.e. include/limits.h) was incorrectly
defining CHAR_MIN and CHAR_MAX as if chars were signed. Since chars are
unsigned in Catalina, these definitions were incorrect, and have been
changed to:
#define CHAR_MAX UCHAR_MAX
#define CHAR_MIN 0
Affected Windows, Linux and Catalyst.
2. Payload was incorrectly sending screen size in response to ESC[6n instead
of current cursor position when used in interactive mode. Affected Windows
and Linux.
3. Payload was misbehaving when "ESC [ nnn C" was sent and C was a very large
number (e.g. 999) when used in interactive mode. The linenoise library does
this to find the length of the line. Now, nnn is limited to the number of
character positions left on the current line. Affected Windows and Linux.
Comments
Just looking at the .lst file and it looks like the answer is $1000 (4 kB). Everything before that looks to be cog0 cogRAM.
Yes, that's usually the case. However, I have a vague memory of using a 256 byte buffer in that low RAM area for something - either in another plugin, or perhaps for loading XMM programs^ - which is so complex it makes my brain hurt just at the thought of having to revisit it
But you should be fine to use it in this case for debugging.
Ross.
^ EDIT: Did a quick search, and couldn't find anything like this. It may have been something I later decided to remove.
Thanks. I've started poking but nothing strongly stood out. The init is completing without error. The CID and CSD do get a different set of numbers but aren't gibberish. Haven't worked out why as yet.
I've made a bit of a mess of the driver so might start over.
Thanks for the efforts. You may be interested to know I have recompiled all Catalyst programs (including Catalina itself) to run at 300Mh using my driver with an SD card delay of zero, and have been doing extensive testing of Cake with it, which (amongst other things) means doing lots of test compilations on the Propeller 2 itself. And I have not seen any SD card lockups since the first few instances.
This is the problem I always seem to have with SD cards - they can work flawlessly for a long time, but occasionally they fail for no apparent reason. I have often wondered if it is the P2 SD circuitry itself, which shares pins between FLASH and SD, and even thought the flash is disabled when the SD card is in use, there may be an issue there - something which your experiences when using different pins for the SD card might also point to - but I am not hardware-savvy enough to really say, and nor do I have the tools to see what's happening at the hardware level
Ross.
The SD/Flash sharing arrangement is pretty bad. It causes strange issues for everyone. It appears most people building custom boards with SD card slots are going for separate pins or 4bit i/f now, at the expense of SD boot.
I only have P2 Edge and P2 Eval boards, but Catalyst can be booted from FLASH instead of from the SD^ - I will try that configuration for a while and see if it makes a difference.
^ To boot Catalyst from FLASH (but also still use the SD card) you set the FLASH switch to ON and the P59^ & P59v switches both OFF. Insert the SD card, but then use flash_payload. For example:
flash_payload catalyst.bin -iMore details in the Flash Support section of the Catalina Compiler Reference Manual for the Propeller 2
Ahhh, I've struck this before. Many SD cards have an internal pull-up on the DO pin, but some don't. Or maybe none do, dunno. At any rate, there is a specific active pull-up in my edited version of the sdmm built-in driver in Flexspin. I keep forgetting it has that. The 4-bit SD mode driver doesn't need it because the add-on board has pull-up resistors on every pin.
When I'm testing non-boot pins I'm using the 4-bit add-on board with the wired pull-up resistors, making the issue go away.
...
I don't understand this bit. How do you implement the pull-up in software?
Configure the output drive to 15K ohms, then drive it high. Or better still, DRVL and use the invert pin drive. Then it happily acts as an input with a pull-up.
Right, good reminder, I gotta get motivated to see if it solves everything or not ...
Hmm, I've just realised I'm getting the identical behaviour with Flexspin's sdmm driver too. It's only happening with one of my uSD cards (Sandisk Extreme 64 GB, dated 2024) and only on the boot pins. Put that same card in the 4-bit add-on slot and no problem with it either. Same for both Flexspin and Catalina compiled programs. The pull-up on DO doesn't appear to be the issue, although without it sdmm can't init any SD card.
Specifically, on every second init sequence the 64 GB SD card is reporting from CMD58 as byte addressable SDSC, and only 30 MB capacity reported in CSD register (CMD9). The card seems to change config somehow. And has probably always done this but I only just noticed first when testing with Catalina.
Scratching my head a little here.
Solved. I've moved R802 to R801 position on the Eval Board, permanently enabling the voltage regular that powers the boot SD slot and Flash EEPROM. This prevents the reset circuit from power cycling these parts.
Here's the supply volts for the power cycle that succeeds in resetting that SD card:
And the one that doesn't succeed:
Neither of them are even close to achieving the SD spec for power cycling. Which is to fall below 0.5 Volt for at least 1.0 millisecond.
PS: I now see another reason I'd hadn't been seeing this earlier. The older Eval Board I have, which is the one I've done most testing with, I'd already moved R802 long ago.
Ross,
There's a chance your random file corruption could be because of this same poor power cycling - Which occurs on each download. I recommend making the wiring change just to take the possibility off the table.
Sadly, I don't have the tools to do it even if I had the eyesight. Also, what would be the equivalent on a P2 Edge board?
Ross.
Ah, it doesn't do the power cycle on reset at all. The SD slot and Flash EEPROM both are supplied direct from the V5663 LDO regulator, whcih in turn comes straight off the common 3.8V switching regulator. Okay, sounds you're getting the identical behaviour on both Eval and Edge. Which then means you're dealing with a different issue than me.
PS: It's the same for most of the EC and EC32MB revisions. The original EC rev A uses a diode drop from 5 Volts instead of the switching regulator for the common to the LDOs but otherwise is the same.
Just thought I'd add a postscript to this. I have been booting Catalyst exclusively from FLASH for over a week now, and running at 300Mhz and with an SD write delay of zero, and have seen no SD card lockups. I have tried two different SD cards (a Verbatim 8Gb and a Sandisk Extreme 32Gb). I have been running extensive Catalina and Cake compilations which make heavy use of the SD card file system, and which can run for up to an hour.
My tentative conclusion is that the SD card lockup occurs on booting from the SD card only.
Another benefit of booting from FLASH is that it speeds up Catalyst as a whole, particularly programs that rely heavily on script execution (such as Catalina itself). For example, here are my current Catalina compilation times on my P2-EC32MB:
program lines time (approx) (mm:ss) ========= ======== ======= hello 5 3:25 othello 500 3:53 startrek 2200 13:49 chimaera 5500 33:20 dbasic 13500 52:10I am yet to decide whether or not to make zero the default delay on SD writes - currently, it is still 10ms. I think I will leave it at that for the next release, but it is configurable on the Catalina command-line, so you can easily set it to zero.
Ross.
Catalina 8.8.3 has been released on GitHub and SourceForge.
This is a full release. It updates Cake, makes the SD Card write delay configurable, enhances Catalyst, and fixes a few minor issues.
Here is the relevant extract from the README.TXT:
New Functionality ----------------- 1. A version of dirent.h, which defines the functions opendir(), readdir(), closedir() and realpath(). These functions are not part of any C standard, but are required by Cake. 2. Cake has been updated to version 0.12.55. 3. Catalina now disables Cake's use of colors in error and warning messages by default, because Geany does not support it. However, for command-line or terminal emulator use, colors can be re-enabled by defining the Catalina symbol CAKE_COLOR, e,g, by adding -C CAKE_COLOR to the Catalina command. For example: catalina hello_99.c -lci -C99 -C CAKE_COLOR 4. printf() (and fprintf() etc) now supports "ll" as a length specified, to indicate a long long - for example "%llu" indicates an "unsigned long long". Note that in Catalina long longs are the same as longs, so in practice both "%lu" and "%llu" will now do the same thing, whereas in previous releases the former would have printed 100 as "100", whereas the latter would have printed it as "100ul". This change was required to support Cake. 5. The Propeller 2 SD card driver (/target/p2/cogsd.t) now allows the SD card delay (in clock ticks) to be specified using the Catalina symbol SD_DELAY during compilation. For example, to set it to zero use a command such as: catalina -p2 -lcx program.c -C SD_DELAY=0 Defining the Catalina symbol NO_SD_DELAY also sets the SD_DELAY to zero, but can be used in build_all scripts. Using NO_SD_DELAY overrides any other specified SD_DELAY. The default if not specified is 10ms, and the driver may not work properly if this delay is altered. 6. In the Catalyst demos folder (demos/catalyst) there is now a build_p2_300 script, which builds Catalyst using a 300 Mhz clock speed (the default of 200Mhz is still used by the build_p2 script). So for example, building Catalyst at 300 Mhz and with no SD_DELAY can be done with a command like: build_p2_300 P2_EDGE PSRAM NO_SD_DELAY Note that 300 baud and no SD_DELAY may not work for all programs, all SD cards, or all Propeller 2 platforms. 7. Catalina no longer defines the symbols "win32", "_WIN32", "_M_IX86" "unix", "i386", "linux" "__unix__", "_i386__", "__linux__", or "__signed__" automatically on any platform. Not defining these symbols may make some programs either not compile, or behave differently. If any of these symbols are required, they can be defined on the command line (using -D). For example: catalina program.c -D__signed=signed 8. Catalina no longer defines the C symbols "__STRICT_ANSI__" or "__STDC__" automatically because this can interfere with the use of Cake as the C preprocessor. Not defining these symbols may make some programs either not compile, or behave differently. If these symbols are required, they can be defined on the command line (using -D). For example: catalina program.c -D__STDC__=1 The C symbol _POSIX_SOURCE is still defined even though Catalina is not fully POSIX compliant, because this symbol enables some necessary definitions in the C header files. 9. The -u option to catalina means it does not delete intermediate files. This is sometimes useful for debugging. On Catalyst (only) it now also means to not run the pstrip utility, which 'strips' comments and blank lines from the intermediate source code files (to reduce their size). 10. Allow -C USE_COLOUR to enable Cake's use of color (i.e. in addition to -C USE_COLOR) and also use the Cake option -fdiagnostics-color=never to disable the use of color. 11. The Catalyst "ls" command has been enhanced to add -a as a command line option. This option includes ".", "..", volume ids and system and hidden files in the listing output, which are now otherwise not included. Also, directory contents are now listed for any directories specified by the command line parameters (previously, a trailing "/" had to explicitly be added to a directory name to print the contents of the directory). Now including a trailing "/" means to list both the directory AND the directory contents. So, for example: ls / will list the contents of the root directory and also the contents of any subdirectories, whereas: ls will list just the contents of the root directory. Similarly: ls -l bin/ will list the long details of the bin directory and also the long details of the contents of the bin directory, whereas: ls -l bin will list just the long details of the contents of the bin directory. Note that the -r flag can be used with or without a trailing "/" on the directory names. Fixed the column and line counting, so the "Continue?" prompt works properly. 12. The Catalyst ls and cat utilities now autodetect the screen size if the VGA, TV and VT100 compatible serial terminal HMI options are used (for serial terminals other than a VT100 compatible terminal, screen size is assumed to be 80x24). Other Changes ------------- 1. The C include file limits.h (i.e. include/limits.h) was incorrectly defining CHAR_MIN and CHAR_MAX as if chars were signed. Since chars are unsigned in Catalina, these definitions were incorrect, and have been changed to: #define CHAR_MAX UCHAR_MAX #define CHAR_MIN 0 Affected Windows, Linux and Catalyst. 2. Payload was incorrectly sending screen size in response to ESC[6n instead of current cursor position when used in interactive mode. Affected Windows and Linux. 3. Payload was misbehaving when "ESC [ nnn C" was sent and C was a very large number (e.g. 999) when used in interactive mode. The linenoise library does this to find the length of the line. Now, nnn is limited to the number of character positions left on the current line. Affected Windows and Linux.