Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 15:48 04 Jul 2025 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : CMM2: Bug reports

     Page 12 of 17    
Author Message
GregZone
Senior Member

Joined: 22/05/2020
Location: New Zealand
Posts: 114
Posted: 11:43pm 17 Jun 2020
Copy link to clipboard 
Print this post

Where can we locate some older MMBasic firmware to try?

Oldest I can find is 5.05.02, which is also the first firmware I loaded after receiving my CMM2 board (and having these issues).

If the board I had was working prior to shipping (presumably with an earlier firmware), then this would seem a logical thing to try next?
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9586
Posted: 12:52am 18 Jun 2020
Copy link to clipboard 
Print this post

Interesting problems going on here.....  

I have played with a couple of my JLC assembled boards.(Peter's PCB design)
The first one has the 753 type V processor on it.

FIRMWARE/PROGRAMMING DETAILS:
A-A lead for programming, Cube 2.1.0 programmer, first 'Final': version 5.05.02, program and verify OK.


PROCEDURE:

- Turn on without battery
- Prompted for keyboard type, date and time [enter them, select US KB]
- Unit resets itself.
- OPTION LIST: reports "OPTION KEYBOAARD US", so that is working for me fine.


My latest batch of boards from JLC are 743 type Y's, so I will finish building one of those and test again.  I will use the same final for these initial tests, and then I can upgrade to the latest beta, and test again and see if I also get the issue, but at the moment, with the 753 V's, I am not seeing any issue with saving the KB date or time.

I have run out of CR1220 batteries, so I will get some more of these, and try both boards with the battery in and see if that returns the same result or not.
Smoke makes things work. When the smoke gets out, it stops!
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6266
Posted: 01:05am 18 Jun 2020
Copy link to clipboard 
Print this post

I would be interested in the serial number reported in Cube.
I am hoping that STM haven't snuck in another version change.

Jim
VK7JH
MMedit
 
GregZone
Senior Member

Joined: 22/05/2020
Location: New Zealand
Posts: 114
Posted: 01:41am 18 Jun 2020
Copy link to clipboard 
Print this post

  Grogster said  The first one has the 753 type V processor on it.

Mine is a Rev Y (400000000).  So that is a point of difference with your test.

  TassyJim said  I would be interested in the serial number reported in Cube.

Here is my STM32CubeProgrammer connect log:

13:27:02 : STM32CubeProgrammer API v2.1.0
13:27:10 : USB speed : Full Speed (12MBit/s)
13:27:10 : Manuf. ID : STMicroelectronics
13:27:10 : Product ID : DFU in FS Mode
13:27:10 : SN : 100364500000
13:27:10 : FW version : 0x011a
13:27:10 : Device ID : 0x0450
13:27:10 : UPLOADING OPTION BYTES DATA ...
13:27:10 : Bank : 0x00
13:27:10 : Address : 0x5200201c
13:27:10 : Size : 308 Bytes
13:27:10 : UPLOADING ...
13:27:10 : Size : 1024 Bytes
13:27:10 : Address : 0x8000000
13:27:10 : Read progress:
13:27:10 : Data read successfully
13:27:10 : Time elapsed during the read operation is: 00:00:00.005


ps. I've also tried doing a "Full chip erase" before programming the firmware.  Made no difference (perhaps as expected?)

Are there any specific Option Bytes that should be manually set (I haven't touhched any!), or are these set in the firmware file?

Only other thought is that if this issue is related to a firmware change (at some point), is it possible this is not being seen in older / existing CMM2's due to some pre-established option / value set by older firmware? ie. That is not being initialised correctly on fresh SoC chips just initially loading the latest firmware?

If this is possible, then perhaps someone with a working CMM2 could do a full chip erase / remove backup battery, to presumably ensure the SoC is reverted to factory shipped status (if my assumption on this is correct)?

On the same thought path, can I get an older firmware image from somewhere to try?
 
KeepIS

Guru

Joined: 13/10/2014
Location: Australia
Posts: 1866
Posted: 01:54am 18 Jun 2020
Copy link to clipboard 
Print this post

Likely of no interest to you but this is from my V chip.

STM32CubeProgrammer API v2.4.0
11:50:14 : USB speed : Full Speed (12MBit/s)
11:50:14 : Manuf. ID : STMicroelectronics
11:50:14 : Product ID : DFU in FS Mode
11:50:14 : SN : 200364500000
11:50:14 : FW version : 0x011a
11:50:14 : Device ID : 0x0450
11:50:14 : UPLOADING OPTION BYTES DATA ...
11:50:14 : Bank : 0x00
11:50:14 : Address : 0x5200201c
11:50:14 : Size : 308 Bytes
11:50:14 : UPLOADING ...
11:50:14 : Size : 1024 Bytes
11:50:14 : Address : 0x8000000
11:50:14 : Read progress:
11:50:14 : Data read successfully

NANO Inverter: Full download - Only Hex Ver 8.1Ks
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6266
Posted: 02:00am 18 Jun 2020
Copy link to clipboard 
Print this post

GreyZone,
Your serial number matches mine for the Y revision chip so I am reasonably certain that the chip is the same.
Likewise for KeepIS V version.

This is firmware from early April
https://www.c-com.com.au/stuff/RC18.zip
I don't think it will help but definitely worth a try.

Peter has already tried a full chip erase.

Jim
Edited 2020-06-18 12:02 by TassyJim
VK7JH
MMedit
 
GregZone
Senior Member

Joined: 22/05/2020
Location: New Zealand
Posts: 114
Posted: 02:57am 18 Jun 2020
Copy link to clipboard 
Print this post

  TassyJim said  This is firmware from early April
https://www.c-com.com.au/stuff/RC18.zip
I don't think it will help but definitely worth a try.

Jim

Thanks Jim. You were correct, we can rule this out.

No change in behaviour after loading this older RC18 firmware. :(

Only other observation is that I'm still seeing the occasional key repeat throughout all these tests, irrespective of firmware version (even on RC18).  

I've also tried alternate USB power sources, just to rule out a power related issue.

I had also (earlier) replaced the 2x 80-pin Header sockets with brand new gold plated sockets, to rule out any Waveshare intermitent connectivity concerns I had (also having no change to the issues faced).
However, as CircuitGizmos has today confirmed the identical issues on his non-Waveshare boards, this kinda rules out my connectivity suspicion anyway.

So... I think I've exhausted the things that I can think of to try. :(
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9586
Posted: 05:29am 18 Jun 2020
Copy link to clipboard 
Print this post

  GregZone said  
  Grogster said  The first one has the 753 type V processor on it.

Mine is a Rev Y (400000000).  So that is a point of difference with your test.


Agreed, but I was just reporting that the V chip does not seem to have that issue.  I will build a Y version tonight from my latest batch from JLC(which are all Y), and see if I can then have the same issues as you are seeing.

If I do, that would suggest something subtle between the V and Y chips is the cause, but what that is exactly at this point.....

I will post back later tonight(my time) once I have had a chance to play with the Y chip board.
Smoke makes things work. When the smoke gets out, it stops!
 
GregZone
Senior Member

Joined: 22/05/2020
Location: New Zealand
Posts: 114
Posted: 06:13am 18 Jun 2020
Copy link to clipboard 
Print this post

  Grogster said  Agreed, but I was just reporting that the V chip does not seem to have that issue.  I will build a Y version tonight from my latest batch from JLC(which are all Y), and see if I can then have the same issues as you are seeing.

Yes, indeed. I was just confirming that mine is a Y chip. I also noted in @CircuitGizmos earlier post that he was using a Y chip when also experiencing the same issues.

So maybe a Y chip firmware issue? Although, @TassyJim posted: "Just tried on my Y and V boards and everything worked as is should."

It will be interesting to see how your Y chip test goes. Perhaps it's just affecting some Y chips? Very strange.
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6266
Posted: 07:05am 18 Jun 2020
Copy link to clipboard 
Print this post

Another test.
Connect a resistor between pin 40 and 3.3V on the output connector.

It can be anything from 1k to about 10k.

If pin 40 is low during bootup, the keyboard gets reset and there could be some stray bleeding to ground.


I really want this solved before Peter wakes up!

Jim
VK7JH
MMedit
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10195
Posted: 07:57am 18 Jun 2020
Copy link to clipboard 
Print this post

Jim's idea seems a likely contender

Attached a version that does 2 things

Patches out the pin 39 test
Does a read test on the options after each write

Remove the battery and the VBAT link.

Install the firmware. Set US keyboard in the initialisation dialogue
Type OPTION LIST to confirm setting
Press the reset switch
Type OPTION LIST to confirm setting

Without a battery the keyboard option should survive pressing the reset button but obviously not a power off


CMM2V5.05.03b1q.zip
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9586
Posted: 08:08am 18 Jun 2020
Copy link to clipboard 
Print this post

OK, completed building of one of the latest JLC boards.
This one uses a 743 type Y chip.
Same A-A program/verify as above.
Same initial 'Final' firmware.

Everything is fine.
I can tell the board I want US keyboard layout, set time and date, board reboots itself, OPTION LIST shows OPTION KEYBOARD US - exactly how it should be.

Still no battery, as I have not had a chance to get more CR1220's, but I hope to test that side of things tomorrow.  Current tests are with the battery OUT.

Press RESET button on the board, then OPTION LIST, and OPTION KEYBOARD US.....

Odd.  

I have not yet updated EITHER of these boards with the latest beta, but that will be the next step, to see if I can then recreate the issue.

My debug from the Y program:

  Quote  19:51:32 : STM32CubeProgrammer API v2.1.0
19:51:36 : USB speed : Full Speed (12MBit/s)
19:51:36 : Manuf. ID : STMicroelectronics
19:51:36 : Product ID : DFU in FS Mode
19:51:36 : SN : 100364500000
19:51:36 : FW version : 0x011a
19:51:36 : Device ID : 0x0450
19:51:36 : UPLOADING OPTION BYTES DATA ...
19:51:36 : Bank : 0x00
19:51:36 : Address : 0x5200201c
19:51:36 : Size : 308 Bytes
19:51:36 : UPLOADING ...
19:51:36 : Size : 1024 Bytes
19:51:36 : Address : 0x8000000
19:51:36 : Read progress:
19:51:36 : Data read successfully
19:51:36 : Time elapsed during the read operation is: 00:00:00.022

Smoke makes things work. When the smoke gets out, it stops!
 
GregZone
Senior Member

Joined: 22/05/2020
Location: New Zealand
Posts: 114
Posted: 08:18am 18 Jun 2020
Copy link to clipboard 
Print this post

  TassyJim said  Another test.
Connect a resistor between pin 40 and 3.3V on the output connector.

It can be anything from 1k to about 10k.

If pin 40 is low during bootup, the keyboard gets reset and there could be some stray bleeding to ground.


I really want this solved before Peter wakes up!

Jim

Jim, you're a miracle worker!

I just soldered a 8K2 pull-up from pin 40 to 3.3V, and we have success!!!

In more detail...

On power-up I was able to successfully set USBKEYBOARD to US and have it retained on the next OPTION LIST.

SD Card still not working.

However, I was then able to do OPTION SD TIMING CONSERVATIVE, and my SD Card "Check Disk" error disappeared!
An OPTION LIST verified that I now had OPTION SD TIMING CONSERVATIVE retained! :)

So it appears that although I'm using a very new 32GB Ultra SANDISK SD Card, I need to use CONSERVATIVE to get it to work.  Is this still a Y chip timing issue?

Finally, one new issue noted. The red BUSY LED now remains permanently on after reset (or power on), until you first acces the SD Card (eg. do an LS command).
 
GregZone
Senior Member

Joined: 22/05/2020
Location: New Zealand
Posts: 114
Posted: 08:21am 18 Jun 2020
Copy link to clipboard 
Print this post

  matherp said  Attached a version that does 2 things

Patches out the pin 39 test
Does a read test on the options after each write

Just to clarify, you want this test done with the pull-up resistor removed?
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6266
Posted: 08:25am 18 Jun 2020
Copy link to clipboard 
Print this post

Bugger.
Now I wish I had bought that new bottle of Whisky yesterday.

Wait for Rob to wake up before getting too excited.

As pin 40 is digital only, you should be able to get away with the resistor in place permanently.
Maybe a higher value but if it works...

Jim
VK7JH
MMedit
 
Chopperp

Guru

Joined: 03/01/2018
Location: Australia
Posts: 1094
Posted: 08:29am 18 Jun 2020
Copy link to clipboard 
Print this post

  GregZone said  So it appears that although I'm using a very new 32GB Ultra SANDISK SD Card, I need to use CONSERVATIVE to get it to work.  Is this still a Y chip timing issue?


I had to use this setting to get a 32GB micro SD card to work (via an adapter) when I was trying to sort SD reading problems out.

I had 1 4GB standard card which worked on & off on normal timing, but not reliable.

Now using on a 4GB micro card on CONSERVATIVE

Brian
ChopperP
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6266
Posted: 08:29am 18 Jun 2020
Copy link to clipboard 
Print this post

  GregZone said  

So it appears that although I'm using a very new 32GB Ultra SANDISK SD Card, I need to use CONSERVATIVE to get it to work.  Is this still a Y chip timing issue?

No, The Y revision are OK, it's the higher capacity SDcards that get fussy.

You can try Peters test firmware with the resistor removed and I expect that it will work the same.

Jim
VK7JH
MMedit
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10195
Posted: 08:30am 18 Jun 2020
Copy link to clipboard 
Print this post

  Quote  Just to clarify, you want this test done with the pull-up resistor removed?


Makes no difference, I've patched out the test. What you need to do is remove the resistor, disconnect everything, and measure the resistance between pin 40 and GND. It should be completely open circuit.

Stupid question but you don't have a bare board sitting on a bench with any conductivity - e.g. antistatic surface

Also, if you have an issue on pin 39, then you almost certainly have other issues on the board and that could be impacting the signals for the SDcard
Edited 2020-06-18 18:36 by matherp
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9586
Posted: 08:47am 18 Jun 2020
Copy link to clipboard 
Print this post

  TassyJim said  Bugger.
Now I wish I had bought that new bottle of Whisky yesterday.
Jim


Vodka is also good!  
Smoke makes things work. When the smoke gets out, it stops!
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10195
Posted: 08:49am 18 Jun 2020
Copy link to clipboard 
Print this post

GregZone

Please could you do another test.

With the CMM2 running normally

SETPIN 40,DIN,PULLUP
? PIN(40)

Then you may wish to repeat on all the other valid pins
 
     Page 12 of 17    
Print this page
The Back Shed's forum code is written, and hosted, in Australia.
© JAQ Software 2025