 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 : ArmmiteH7 V5.07.00b6 - Major performance hike
  Page 3 of 3 |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
ArmmiteH7V5.07.00b14.zip Fixes the pause issue Other changes form Geoff's latest release: Bug fix for STATIC variables as reported by thwill Much improved performance for reading DATA statements Also, includes BITBANG command as per CMM2 |
||||
KeepIS Guru Joined: 13/10/2014 Location: AustraliaPosts: 1882 |
Unfortunately when I try to set OPTION LCD screen, the device hangs. It takes a few options correctly but always hangs on the LCD. OPTION LCDPANEL SSD1963_8_16, LANDSCAPE ARMH7-1 now hangs, reset, power cycle but nothing can bring it back to life except a re flash, and then the cycle repeats. Using STLink to erase and program? . NANO Inverter: Full download - Only Hex Ver 8.1Ks |
||||
| KeepIS Guru Joined: 13/10/2014 Location: AustraliaPosts: 1882 |
And confirmed on the H7Z-2, option Lcdpanel kills the device, and only OPTION LCDPANEL, every other option completes correctly. On the plus side, the bitbang command works nicely  And the Pause command appears to be fixed  . Edited 2021-06-17 14:51 by KeepIS NANO Inverter: Full download - Only Hex Ver 8.1Ks |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
ArmmiteH7V5.07.00b15.zip Fixes the LCD problem - nothing to do with options - caused by the pause change Edited 2021-06-17 20:26 by matherp |
||||
| KeepIS Guru Joined: 13/10/2014 Location: AustraliaPosts: 1882 |
All good NANO Inverter: Full download - Only Hex Ver 8.1Ks |
||||
HardingJohn Regular Member  Joined: 28/07/2017 Location: AustraliaPosts: 78 |
I have built 5 devices that all use the STM32H743ZIT6 480Mhz chip. They all work fine with ver 5.05.11. at 480Mhz. However on updating to the new ver 5.07.00b11 or 5.07.00b15 only two of the five will boot after firmware upload. I have tried reinstalling the earlier firmware and they boot fine again. Yet on changing to the newer version they just wont boot. I can not work out why only 2 of the 5 work with the new 5.07?? Can anyone think why? I have used the same crystals and have the same decoupling caps across the 5 units. It does not seem to matter whether an LCD screen or other devices are using the SPIs. Just know enough to get me in trouble, but not quite enough to get me out. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
It is probably that the options are different. When you program do a flash erase all and then remove the battery before powering up. This will ensure the firmware re-initialises the options. Assuming this works re-install the battery and carry on |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5091 |
Hi HardingJohn, I do not have a H7 board, but I do own a CMM2. And I recall there has been a change in where the OPTION information is stored. That used to be in CMOS memory (battery backed) but due to problems people had when the battery drained, it has recently been moved into flash memory. Maybe that is the case, and you should reset all options, and init them again. PicomiteVGA PETSCII ROBOTS |
||||
| BrantB Newbie  Joined: 27/10/2017 Location: CanadaPosts: 40 |
@HardingJohn ... did you ever get your issue with programming newer firmware worked out? Did doing a flash erase before programming work for you? I asked, because I have experienced similar types of things with my Nucleo (ver 2) board. I have always been able to program 5.05.10 into it without any difficulties, and it always seems to be reliable. But, when I try to use 5.07.00b12 or b13, things go flaky on me. I have not been able to put my finger on it. I rarely seem to be able to successfully program b12 or b13 directly - most times have to program in 5.05.10 first, see the Micromite prompt, and then I can get b12 or b13 to take hold after that. But even then, the chip seems to lose its brains after a few power cycles. It just won't come to life again. Sometimes it will hold onto its brains for weeks, and the next power up is fine. Other times, I can shut down for the day (having done several power cycles while tinkering), and then the following day it fails to start up. It is never totally bricked - I can always start life over again with 5.05.10. (Oh, by the way - I don't have a battery involved here, and I don't have the Nucleo backpack board involved. I also followed the other threads related to the differences between the original Nucleo and Rev 2, and the corresponding solder blob configurations that are required. I think that should pre-answer some obvious questions  )At on point, I began to wonder if there was something going wonky with the built-in ST-LINK module (though I would have expected the Internet to be blowing up with such reports already if that was the case - so I wasn't really holding my breath). To test that theory, I was looking at the possibility of configuring the built-in ST-LINK module to be disabled (Hi-Z mode) - after programming, of course  - and hooking up a TTL/USB dongle directly to the console signals. But they don't seem to be brought out on readily accessible header pins on the Nucleo board - at least not without messing about again with solder blobs (which I would likely end up having to remove again, anyway, after the tests).Because this is a Nucleo, with a built-in ST-LINK supporting the EMBED protocols, I just use the drag-n-drop method with the BIN file to do the programming. To be honest, I don't know if that first goes through a flash erase or not. If it does, then my issue is still a mystery. If it doesn't - well, I guess I will have to look into using the ST-LINK software rather than the EMBED drag-n-drop method, so that I get a chance to force a full erasure, first. Having said all that, I have just discovered the 5.07.00b15 version of the firmware, and I am just starting to give it a try. We'll see how it goes. I have also just discovered the OPTION RESET functionality  , so maybe that will help too.Anyway, I would be interested in any feedback / insight. Cheers, Brant |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2642 |
Might not be relevant to the H7, on the F4 I had a similar problem. The firmware prog. jumper is is set to Gnd. for normal use but wasn't making contact leaving the pin floating. Program and options would randomly vanish at powerup. A new jumper fixed it. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
ArmmiteH7V5.07.00b16.zip New math command MATH M_INVERSE array!(), inversearray!() This returns the inverse of array!() in inversearray!(). The array must be square and you will get an error if the array cannot be inverted (determinant=0). array!() and inversearray!() cannot be the same. New math function MATH(M_DETERMINANT array!()) returns the determinant of the array. The array must be square Enhancement of the RESTORE comand The restore command can now take a variable as the parameter. A numerical variable should be used for a line number and a string variable for a label Enhancement of the READ command The read command can now take arrays as one or more of the parameters. As usual arrays are specified with an empty set of brackets. NB: I've tested this release on both a NUCLEOH743ZI and a NUCLEOH743ZI2 using both an overwrite and after a full chip erase and in all cases it starts running perfectly. You should be aware with the ZI2 of one possible issue. There is a design flaw on the ZI2 that doesn't exist on the ZI. The ST-LINK in both cases generates the 8MHz system clock for the H743. In the case of the ZI this is derived directly from the crystal clocking the ST-LINK V2 circuit. In the case of the ZI2 it is derived from the internal RC oscillator on the ST-LINK V3 processor. i.e. not very accurate. There is now new firmware for the V3 which has the option of using a crystal derived clock but it isn't at 8MHZ but rather 8.33MHZ  . To me this compounds their stupidity of using the internal clock in the first place. This seems to be a setup option when updating the firmware in the ST-LINK. DO NOT choose this option if presented with it. Note also that I always use the ST-LINK to update the firmware rather than dragging the .bin file |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
@phil99 - Very interesting "war story" about the flaky jumper. Over the years, I have amassed similarly strange memoirs of things I have run into - but that one, specifically, is new to me. There are only a few jumpers involved on the H7 Nucleo boards, and I have did my best to check them in-situ - all seemed well. Checking for continuity using a pair of header pins (isolated, off-board) has also reinforced that they appear to be okay. But thanks for the tip - you just never know when that little pearl of wisdom might come in handy one day. @matherp - Thanks for the updated firmware, and for the clarification regarding the use of the ST-LINK utility. And, your note about the clock source on the ZI2 board piqued my interest. Luckily, I had not run into the 8.33MHz issue, even though I had already upgraded the ST-LINK firmware to the latest V3(J8M3) level. I will definitely keep that front of mind in the future, if I ever have cause to upgrade the firmware again. Somewhere along the line, I guess I gained the misunderstanding that the drag-and-drop method of programming the BIN file had become the go-to approach. Early on, I was very clear on the point about avoiding the Cube utility like the plague, and that ST-LINK should be used instead. But somewhere along the way I thought the dragging technique entered the ring and that, since then, no one ever looked back. Clearly, I was mistaken. Anyway, I am glad to report that I had instant success with programming the latest (b16) firmware into my Nucleo ZI2, using ST-LINK. (Well, that is, once I actually figured out where ST was hiding the download page for the utility .) A full chip erase ... program/verify ... fire up my terminal program ... reset ... voila! The ARMmiteH7 prompt showed up right away.I have not done anything tremendously serious with it yet to exercise it and bolster my confidence in it - but early indications are certainly very encouraging. Cheers! |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3378 |
Drag and drop has been my practice since I found out about it, and I haven't seen any problem. But I haven't use the H7 in a year or so. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| HardingJohn Regular Member Joined: 28/07/2017 Location: AustraliaPosts: 78 |
Finally got around to looking at this again. I use the break-off Stlink 2 from an old Nuclei STM32H743ZI board to load firmware into both the old VI (ver Y) and the newer VI2 (ver V) chips on my own custom boards. I think there is an issue with using Stlink V2 to load 5.07.00b16 into the newer STM32H743VI2 (ver V) chip. You can successfully load both 5.05.11 and 5.07.00b16 into the older STM32H743VI (ver Y) and both run fine, but only 5.05.11 will run on the newer ver V chip. I think Stlink V2 is doing something to prevent 5.07.00b16 from running on the VI2 (ver V) chips, yet allows 5.05.11 to run fine?? Should I purchase the Stlink V3MINI Programmer or can I wire in a USB port to the chip to directly upload 5.07.00b16 to fix this problem?? Will C-functions ever be added to 5.07.00b16 or am I forced into redesigning everything around the STM32H743IIT6 176 pin chip?? To Peter Mather, thanks for everything you and Geoff have done. Just know enough to get me in trouble, but not quite enough to get me out. |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
@HardingJohn That thing is literally break-off? I mean it looks like it but I never thought about it. Would love to learn more about your custom version |
||||
| HardingJohn Regular Member Joined: 28/07/2017 Location: AustraliaPosts: 78 |
@Tinine My device has the following functions. 1. LoRa 1 watt wireless networking with a sudo mesh protocol over 915-928 Mhz. 2. Ethernet 100Mb/s with 8 consequtive sockets. 3. TCP Modbus Wireless Gateway. 4. RTU Modbus RS485 Wireless Gateway. 5. HTTP port 80 web page server. 6. Websocket upgrade for interactive web page. Future MQTT websocket connection. 7. 3 phase AC Metering class 0.5. 8. 4 X DI + 4 X DO peer to peer digital IO. 9. IGMP TCP Modbus broadcasting. 10. SDcard Data logger. 11. Colour touch screen. 12. Cryptography chip for private/public key encryption, decryption and key storage. 13. MMBASIC PLC. 14. DIN rail mounted enclosure external SMA socket for Antenna. Objective: Secure encrypted wireless trading system to buy or sell energy across a local electrical distribution grid and maintain grid voltage and frequency. Modbus control & comms with PV And Battery Inverters to provide behind the Meter trading and future peer to peer trading across the local electrical network. Off grid and micro- grid AC coupled PV and Battery Inverter active and reactive power limitation and control. Energy management and control of distributed generation and loads across micro-grids. Flexible and simplistic programming language to allow easy modification to suit each sites unique requirements. 5 units built and tested, but need to consider upgrade to the STM32H743IIT6 chip to benefit from C-functions to speed things up. Just know enough to get me in trouble, but not quite enough to get me out. |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
OUTSTANDING!!! Very impressive |
||||
| Page 3 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
