My RTC is at the usual 0x68 address. RTC gettime appears to work as generates no MM.Errno error yet sets the Pico clock to 00:00 31-12-1999 !
My own RTC program is still working perfectly and displays the correct date and time as expected….
What RTC are you using ? DS3107, DS3231, PCF8563, RV3028 ?
For the community: small correction needed, nothing to worry about.
But there is an important message: be aware that the I2C addresses 0x68,0x51,0x52 should not be used on the system I2C bus except for RTC devices.
The problem is that an FRAM has been connected to the I2C bus with the address 0x51 and was “mistakenly” seen as an RTC device.
Yes that was me lol. Problem sorted by avoiding use of the ‘RTC Gettime’ command and setting date/time directly from a combination of the RTC’s registers instead….
Found a bug. Playing any mp3 that worked well under 6.00.01 from adcockm now causes a crash !. Sometimes ‘address error’ appears very briefly, sometimes boots to the default MMBasic startup screen and needs OPTION AUTORUN 1 again to fix autorun….
Does anyone know the purpose of the .vars file on the A: drive? On my device it’s about 162kB and is dated 00-00-1980.
I did a search through this forum and the User’s Guide without success.
Can you reproduce this error using the “official” release ? I have seen some hints that there might be a problem in this area using the “official” release and there are no updates coming in at the moment.
See the manual: SAVE CONTEXT
Saves the variable space and optionally clears it - command should be used in top level program and not from within a subroutine. This saves the entire variable space to the A: drive. The command will fail if there is not enough free space on the A: drive. In the case of and RP2350 with PSRAM the variable space will be saved to a reserved area in the PSRAM and the A: drive is not used.
See also LOAD CONTEXT
Any program using this command will update the file “.vars”
Since the RTC correction isn’t in RC27e, can you show us where it is so we can implement it ourselves until the next RC comes out?
The correction is in the current download, I did update the RC27e archive. The change in is I2C.c where lines 1123-1124 have been moved up so that 0x68 is checked before 0x51 and 0x52
RTC_Addr = 0x68; // DS1307 / DS3231
if ((i2c_read_timeout_us(i2c1, RTC_Addr, (uint8_t *) buff, 1, false, 10000)) > 0) return RTC_Addr;
RTC_Addr = 0x51; // PCF8361
if ((i2c_read_timeout_us(i2c1, RTC_Addr, (uint8_t *) buff, 1, false, 10000)) > 0) return RTC_Addr;
RTC_Addr = 0x52; // RV3028
if ((i2c_read_timeout_us(i2c1, RTC_Addr, (uint8_t *) buff, 1, false, 10000)) > 0) return RTC_Addr;
1 Like
OK, I can use RTC AUTO ENABLE now. I missed the updated version somehow. Thanks!
Can you please tell me what does “Peter’s source” mean?
Peter Mather, author of MMBasic. Unrelated to Clockwork hence the need to modify for use on the Picocalc.
Fine, but where is it?
Have a look through this thread and where it points to… Note that updates are appearing often.
Go here:
MMBasic Source
It’s not written for PicoCalc but it will run on bare chips as well as VGA and HDMI systems. You have to edit CMakeLists.txt to tell the compiler which version to compile. Follow the instructions EXACTLY
Okay, it is clear that it is the non-picocalc source. Thank you.
Installing the RP2350 (any version, e.g. VGA, WebMite, USB, etc) .uf2 of 6.01.00 on my Pico 2W results in the system booting, coming up with the MMBasic header, then the screen turning off after 3-5 seconds.
I’ve tried multiple RCs for 6.01.00, going back to RC19 and they all exhibit this behavior. The only version that boots properly is 6.00.02.
Yes, I’ve tried up to rc27a. Same issue. I’ve tried doing a zero out of my Pico 2W. No change. 6.01.00 just does not work on mine, 6.00.03 does. Machikania 1.6.1 does work perfectly.
Are there logs anywhere I can get to help?